What Decides Whether A Web Application Is Safe To Ship

Where Should A Web Application Project Start?

Specify who can see what and who can change what, per role, before anyone draws a screen.

That is access control, it is the top category on OWASP's 2025 list, and it is the one thing in a web application that cannot be retrofitted cheaply. Everything else in a build can be changed later at roughly the cost of doing it. Access control cannot, because by then the assumptions are spread across every endpoint you wrote.

Then read the rest of the list, because two of the ten are things briefs almost never mention.

The Finding That Should Change Your Brief

Read the OWASP wording carefully, because it is precise and the precision matters.

A01:2025 Broken Access Control sits at number one. Forty distinct Common Weakness Enumerations map to it. The average incidence rate is 3.74%, and the contributed data records 1,839,701 occurrences. OWASP also notes the category carries the second highest count of related CVEs in the whole Top 10.

And: 100% of the applications tested were found to have some form of broken access control.

That last figure is about applications that were examined for it. It is not a claim about every application in existence. But it is a claim about what happens when somebody looks properly, and if you are commissioning a build, you are commissioning something that will eventually be looked at properly.

Access Control Is Not A Component

The reason this category stays at the top is structural rather than careless.

Authentication is a thing you can install. It has a clear boundary, mature libraries and a single question: is this the person they claim to be. It gets done, because it is visible and because nothing works until it is.

Authorisation is not one thing. It is a separate decision at every endpoint, every query, every file, every identifier that appears in a URL. Can this user read this record. Can they change it. Can they see that it exists. Can they see it belongs to someone else. That decision has to be made correctly a few hundred times, by different people, over several years, and it is wrong the first time somebody forgets.

No framework removes that. A framework can give you a good place to put the decision, and the better ones make forgetting harder. None of them can tell you what the rule should be, because the rule is about your business.

Which is why the answer belongs in the brief, in your words, before the first screen is drawn.

The Entry Most Briefs Do Not Cover

The 2025 list has Software Supply Chain Failures at number three.

That is a broader category than the dependency scanning most teams already do. It covers what you pull in, where it came from, what it pulls in behind it, and what happens in your build pipeline before anything reaches a server.

A custom web application is mostly other people's code. That is not a criticism, it is how everything is built now, and rewriting it yourself would be worse. But it means the honest question in a brief is not whether you use dependencies. It is who is responsible for knowing what changed in them, on what cadence, and what the process is when something in that tree turns out to be hostile.

In my experience that question has no owner on most projects, because it is nobody's feature.

What The Bottom Of The List Is Really About

A10:2025 is Mishandling of Exceptional Conditions. It reads like a technicality and it is not.

It is the category for what your application does when something happens that nobody planned for. The payment provider times out halfway. The upload is a valid file of the wrong kind. Two people submit the same form at the same second. The database is briefly unreachable.

Applications rarely fail in the paths that were designed. They fail in the paths that were not, and the difference between a bad afternoon and a serious incident is usually what the code did on the way down: whether it failed closed or open, whether it left a half written record, and whether anyone found out.

That connects to A09:2025, Security Logging and Alerting Failures. If it goes wrong and nothing tells you, the incident does not start when it happens. It starts when a customer notices.

Why Per Screen Pricing Hides The Cost

Screens are countable, which is why quotes are built from them. The problem is that almost nothing expensive scales with the screen count.

Take an application with eight screens and four roles. The screens are eight pieces of work. The permission rules are closer to eight multiplied by four, and that is before anything appears on more than one screen or belongs to more than one owner. Add a fifth role in month six and no new screens are drawn, but every rule has to be revisited.

The same applies to failure handling. Two external dependencies do not mean two error paths. They mean every combination of one being slow, one being down, both being unavailable at once, and either one answering something plausible but wrong.

None of that shows up in a per screen estimate, so it gets absorbed by whoever is building, usually by making the simplest assumption available at the time. The simplest assumption in access control is that the current user is allowed. The simplest assumption in failure handling is that the call worked.

Both are the wrong default, and both are how an application ends up in OWASP's data.

This is not an argument for a bigger budget. It is an argument for putting the rules in the brief, where they can be discussed once, rather than leaving them to be invented a few hundred times by whoever is on that ticket.

What To Put In A Web Application Brief

Four things, none of which are screens.

A role and permission table. Every role, every object, and read, write and delete marked for each. One page. Doing this before design regularly changes what gets designed, because it exposes rules nobody had stated.

What happens on failure, per integration. For every external system you depend on, what the application does when it is slow, when it is down, and when it answers wrongly. Failing closed is a decision; failing open by accident is what happens without one.

Who watches the dependency tree. A named owner, a cadence, and what triggers an out of cycle update.

What gets logged, and who is told. Which events, retained how long, and what raises an alert rather than a line in a file nobody reads.

Those four fit on two sides of paper. They are cheap to write and expensive to add later, which is the definition of something that belongs in the brief.

Signs Your Web Application Brief Has A Gap

Five signals.

1. The quote is priced per screen and there is no line for roles and permissions.
2. Nobody can produce a table of who can read and change each type of record.
3. Authentication is specified in detail and authorisation is described as "user levels".
4. Nobody owns the dependency tree, and the last update was whenever something broke.
5. You would find out about a serious failure from a customer rather than an alert.

Signal three is the common one. It reads like the question has been answered because a login was discussed, and OWASP's top category is about everything after the login.

If any of those apply, you can Request The Free Scoping Audit. The What We Build section is on the main site.

Common Questions About Web Applications

What Is Custom Web Application Development?

Building software delivered through a browser and shaped around one organisation's processes, rather than adapting the organisation to a package. The work is mostly rules: who can do what, what happens when an external system fails, and what the application records about both. Screens are the visible part, not the expensive part.

What Is The Biggest Web Application Security Risk?

Broken access control. It is category A01 in the OWASP Top 10:2025, with 40 mapped weakness types and more than 1.8 million recorded occurrences in the contributed data. OWASP reports that 100% of the applications tested were found to have some form of it.

Why Can Access Control Not Be Added Later?

Because it is not one component. Authorisation is a separate decision at every endpoint, query and identifier, so the assumptions spread through the whole codebase as it is written. Retrofitting means revisiting all of them. Authentication, by contrast, has a clear boundary and can be added or replaced.

What Should A Web Application Brief Contain?

A role and permission table covering read, write and delete per object. What the application does when each external dependency is slow, down or wrong. A named owner for the dependency tree with an update cadence. What gets logged, retained how long, and what raises an alert.

Is Software Supply Chain Really My Problem?

OWASP placed Software Supply Chain Failures third in the 2025 list, so it is treated as a top tier application risk rather than a vendor concern. A custom application is largely other people's code, which means someone must own knowing what changed in it and what to do when something is hostile.

Part of The Development Guide. See also Systems Integration Is A Language Choice, Not A Purchase and How To Decide Whether To Build Or Buy.