A web application is rarely just a page with a contact form these days. Most often it is the heart of the company. Customer data, invoices, ERP integrations and the business logic that revenue depends on all flow through it. And when a system like that fails on security, the problem does not end with a moment of downtime. It reaches much further. At Web Systems we have been designing and maintaining web applications, B2B systems and API integrations since 2006, so we know that moment all too well – when a seemingly minor oversight turns into a costly incident.
Spis treści
Why web application security decides whether a project succeeds
Every web application is a gateway to the data of the company and its customers. One leaked database with addresses, passwords or order history is enough for the losses to exceed the cost of the entire implementation. Because what you pay for then is not only patching the hole. There is legal support, notifying the people affected and rebuilding trust, which you cannot buy in a package of development hours.
The worst mistake we see over and over? Treating protection as an add-on, glued on quickly just before launch. Yet security is an architectural decision. You make it on day one of the project. How passwords are stored, the permission model, the separation of layers, session handling – all of it shapes every line of code written later. Bolting security onto a finished, badly designed system is usually an expensive refactor, not a simple fix.
And here is something important from the contractor’s perspective: the risk does not rest on the client alone. A GDPR violation, a financial penalty or a public reputational crisis also hit the software house that built the system. That is why we look at software development and data protection as a shared interest. Not as a line item you cross out to fit the budget.
It is worth separating two kinds of cost. The first is a predictable investment in good practices – spread over time, quantifiable, something you can plan. The second is an emergency expense incurred after an incident, when time pressure and bad press push the rates through the roof. A solid technology partner helps the client stay on the right side of that equation before anything goes wrong. The decision about priorities is made at the very beginning. And its consequences run through the entire product life cycle.
The most common security gaps we see in projects we take over
When we take over someone else’s code, we usually run into the same set of problems. The same ones again and again. SQL Injection, XSS and CSRF still rule, even though we have known about them for years. The source? Almost always a lack of input validation. Queries assembled from text typed in by the user, content injected into the page without filtering, forms with no tokens to protect against request forgery.
The second recurring category is broken access control, meaning faulty permission checks. Accounts with excessive privileges, no verification of whether a given user is entitled to a specific record at all, admin panels shielded by nothing more than a non-obvious URL. That kind of protection through obscurity falls in a second once someone guesses the path or swaps an identifier in the request.
Secrets deserve a chapter of their own. Database passwords, API keys, integration tokens – they land straight in the repository or in configuration files, without a trace of encryption. And one carelessly shared commit is all it takes for access credentials to sit in plain view for months.
During an audit of inherited code a few sins come back regularly:
- libraries and frameworks in versions with publicly known vulnerabilities,
- no limits on the number of login attempts, which opens the door to brute-force attacks,
- error messages revealing the database structure or server paths,
- files uploaded by users without any control over type and size,
- sessions that never expire and cookies without security flags.
All these flaws share one common denominator. They exist because security was not part of the process, only an afterthought. Tip: if you are taking over a project from another contractor, start with a dependency audit and a review of the permission model. That is where the nastiest surprises usually hide.
What a good software house implements by default – standards and practices
A reliable contractor does not ask whether to turn on basic protections. They simply turn them on, because that is the standard. The first pillar is encryption. All transmission goes through HTTPS and TLS, and sensitive data in the database – personal data, payment details – is additionally protected so that intercepting it does not immediately mean full disclosure.
The second pillar is authentication. Passwords are never stored in the clear, only as strong hashes made with a decent algorithm. Where the risk is higher, 2FA comes in along with short-lived tokens that are worthless to an attacker once they expire. And for integrations and external logins we reach for proven standards such as OAuth2 instead of cobbling together our own fragile solutions.
The third pillar is discipline on the server side. Every piece of input goes through validation and sanitization, regardless of what happens in the browser – because frontend protections are bypassed with a flick of the wrist. We consistently stick to the principle of least privilege: a user, a service and a process get exactly as much access as they need to do the job. And not a bit more.
So that these rules do not depend on one developer’s memory, we rely on a structured checklist. Tip: every project should start with a ready OWASP Top 10 checklist, worked through deliberately already at the design stage. Not ticked off in a hurry five minutes before launch.
Default good practice also includes order in the handling of secrets. Keys and passwords stay outside the repository, in dedicated configuration stores, with the test and production environments separated. Thanks to that, an accidental code leak does not immediately expose access to the data. Protection understood this way becomes a predictable foundation on which you add new features without a constant fear of security regression.
Security versus architecture and API integrations
A resilient application starts with good architecture. Separating the layers, so that presentation, business logic and data access have clear boundaries, gives you real control over who can do what. Isolating services means that a problem in one module does not immediately spill over into the whole system. And B2B integrations designed with trust in mind allow data to be exchanged safely between organizations.
APIs deserve particular attention. Because that is how systems talk to each other and to partners. We use request limits, that is rate limiting, so that a single client cannot overload the service or use it to scrape data in bulk. Access is based on API keys and tokens, and in B2B communication request signatures and encryption are added – thanks to which the recipient can be sure the data came from the right sender and nobody tampered with it along the way.
A well thought out architecture also pays off later, whether we are talking about a complex B2B system or modern website development with elaborate logic. A clear division into modules, a single source of truth for each type of data, a predictable flow of information – all of it makes patching vulnerabilities and scaling without downtime easier. Need to update a single component? You do it without stopping the entire platform.
Practical decisions worth making at the start include:
- separating the data access layer, so that security rules live in one place instead of being scattered across the code,
- versioning the API, so that changes do not break integrations at your partners,
- separating environments and configurations, which limits the blast radius of a potential error.
With this approach security does not fight against scalability. It goes hand in hand with it. A system designed in a modular way is easier to audit, test and develop, and every new integration adds to a coherent whole instead of creating another poorly guarded entry point.
Maintenance, updates and monitoring after launch
Security does not end on launch day. The libraries and dependencies an application stands on grow old, and new vulnerabilities keep turning up in popular packages. A system that was secure a year ago may have a known gap today – simply because nobody took care of updates. That is why we treat maintenance as a permanent part of the cooperation, not a service triggered only after a failure.
The second pillar of the maintenance phase is visibility into what happens in the system. Without event logging and anomaly monitoring you usually notice an incident only when the damage is already considerable. A sensible set includes recording significant operations, alerts about unusual traffic patterns, regular backups and a tested disaster recovery plan. Because a backup nobody has ever tried to restore is a false sense of security. Nothing more.
Look at the cost of maintenance as an investment, not a burden. Planned updates and monitoring are cheaper and less stressful than putting out a fire in the middle of the weekend, when the application is down and data may have leaked. Prevention almost always costs less than reacting to a risk that has already materialized.
Tip: plan regular audits and penetration tests, especially after bigger changes – a new integration, a data migration or the rollout of another module. It is exactly after larger modifications that a new vulnerability is easiest to let in unknowingly.
A good habit is agreeing a clear maintenance rhythm with the contractor. Who checks for updates and how often, what the incident response procedures look like, how quickly the service comes back after a failure. Such a plan turns security from a declaration into a measurable process you can rely on throughout the life of the product. Also long after the main implementation stage is finished.
FAQ – the questions clients ask most often about application security
A few questions come back like a boomerang in conversations with clients. We have collected the most common ones together with the answers we usually give at the quoting and planning stage.
Does a small project also need enterprise-level protection?
Scale can be misleading. Even a small application, if it processes personal data or payments, is subject to the same regulations and the same automated attacks as large systems. Bots scanning the internet do not check the size of the company. They check for the presence of known vulnerabilities. That is why the basics – encryption, correct authentication, data validation – always apply. The difference lies in the proportions: a smaller project does not need elaborate corporate-grade mechanisms, but the foundation has to be solid regardless of scale.
How much does it cost to implement an adequate level of security?
There is no single figure, because the cost depends on the sensitivity of the data, the number of integrations and the legal requirements. But there is another, more important observation: security built in from the start is relatively cheap, because it follows from good design decisions rather than from extra work. It gets expensive only when it has to be added to a finished system or when the effects of an incident have to be undone. The most sensible approach is to treat it as a permanent part of the implementation and maintenance budget. Not as an optional extra.
What to do when someone else wrote the application and we do not know its condition?
A common situation, and one that can be handled. We start with an audit – a review of dependencies, the permission model, how secrets are stored and the most exposed features. The output is a list of vulnerabilities ranked by risk. It lets us patch the most dangerous items first and plan the calmer clean-up work for later. Such a review also gives a realistic picture of the technical debt before you decide on further development or a modernization of the system.
Summary – what to require from your contractor
The most important conclusion is simple. Security is a process, not a one-off feature you tick off and forget. Demand it at every stage – from the first architectural decisions, through coding and integrations, to maintenance long after launch. A contractor who starts talking about data protection only at project handover gives themselves away: they treated it as an add-on, not a foundation.
You recognize a reliable partner by a few concrete signals. They know and apply the OWASP Top 10. They describe their practices openly instead of hiding behind generalities. They propose a clear permission model and a maintenance plan with updates, monitoring and backups. And they can explain their decisions in language a non-technical person understands, tying them to real business risk.
What to look at when choosing a contractor:
- whether security comes up already at the quoting and design stage,
- whether secrets and keys are kept outside the repository,
- whether there is a plan for updates, monitoring and incident response,
- whether the contractor proposes an audit and tests after bigger changes.
At Web Systems we treat these questions as standard, because since 2006 we have been designing, delivering and maintaining web and mobile applications, B2B systems, API integrations, automations, e-commerce and AI solutions. We know how to combine security with scalability and a sensible budget. Without empty marketing.
Are you planning a new product, an MVP, an integration, an AI rollout, process automation or the modernization of an existing system? Get in touch with the Web Systems team – we will help you assess the risks and design a solution that is secure from day one.
