Blog
Key takeaways:
Web application security work has a bad habit of arriving as a list. Ten things, twenty-five things, a vendor checklist with four hundred rows, and no indication which of them matters for the application you actually run.
So this guide takes the opposite approach. It starts from the two sources that count real web application security flaws in real software, works out what they agree on, and then says where to put your first week of effort.
The short version is that the industry's own data points at access control, configuration and dependencies. All three are within reach of a small engineering team, and the expensive tooling can wait.
Web application security is the practice of protecting the application layer: your code, your data model, your sessions, your dependencies and the configuration they run under. It sits above network and endpoint security, and it is the layer you wrote yourself.
That distinction matters more than it sounds. A firewall vendor can ship a rule that blocks a known attack pattern for every customer at once. Nobody can ship a rule that knows whether user 1182 is allowed to read invoice 4471, because only your application knows that.
So the controls split into two groups. There are the generic ones, where a library or a platform setting does the job properly and you should use it. And there are the ones specific to your domain, where the only defense is code you wrote and tested on purpose.
The breaches that do the most damage tend to land in the second group. The surface you are defending also depends on how users reach you, since a mobile client moves part of it onto a device you do not control, which is one reason the choice between web and mobile apps is an architectural decision rather than a marketing one.
Two sources are worth your time, and they are built differently. The OWASP Top 10 is a consensus list of risk categories, drawn from scan data contributed across a large sample of applications plus a practitioner survey. MITRE's CWE Top 25 ranks individual weakness types by how often they appear in published vulnerabilities and how badly they go wrong.
The 2025 OWASP list is the eighth installment, with two new categories and one consolidation. Reading it next to the CWE rankings is more useful than reading either alone, because the two disagree in an informative way.
| OWASP 2025 category | Rank (2021 rank) | Share of apps tested | CWEs in category |
|---|---|---|---|
| Broken Access Control | 1 (1) | 3.73% | 40 |
| Security Misconfiguration | 2 (5) | 3.00% | 16 |
| Software Supply Chain Failures | 3 (expanded from 6) | lowest in data | 5 |
| Cryptographic Failures | 4 (2) | 3.80% | 32 |
| Injection | 5 (3) | not stated | 38 |
| Insecure Design | 6 (4) | not stated | not stated |
| Authentication Failures | 7 (7) | not stated | 36 |
Look at the third and fourth columns together. Cryptographic failures turned up in 3.80% of applications tested, a higher share than broken access control at 3.73%, and still rank three places lower.
OWASP weighs exploitability and impact alongside how often something appears, and it also promotes two categories each cycle on the strength of its community survey rather than the contributed data. Supply chain failures reached number three by both routes at once: practitioners voted it an overwhelming top concern, and it carries the highest severity scores on the fewest occurrences in the whole dataset. So treat the list as a priority order rather than a tally.
MITRE's 2025 CWE Top 25 is drawn from 39,080 published vulnerability records. Cross-site scripting leads it with a score of 60.38, more than double SQL injection's 28.72 in second place.
The pattern underneath those two is the useful part. Four of the 25 entries are authorization failures: missing authorization at number four, incorrect authorization at seventeen, improper access control at nineteen, and authorization bypass through a user-controlled key at twenty-four.
None of the four fell in the rankings. Missing authorization climbed five places, the bypass entry climbed six, and improper access control is new to the list this year.
Laid out across all twenty-five positions, the four sit apart from each other.
Authorization is hard because the rule lives in your head. A scanner can tell you a query is unparameterized, since that is a property of the code. It cannot tell you that a sales rep should see their own accounts and not the whole region, because that fact exists only in a conversation somebody had with your customer.
The most common version is an identifier in a URL or an API path that nobody checks ownership on. Change /invoices/4471 to /invoices/4472 and see what comes back. At VAULT we find this in codebases we inherit often enough that it is the first thing we look for, usually in endpoints added late under deadline pressure rather than the ones designed up front.
User-uploaded files are where it bites hardest, because the file usually lives outside the database, so the ownership question travels with it rather than staying in a table you already filter.
Keep the objects in a store like S3, record who owns which object in your own database, authorize every request against that record, and hand the browser a short-lived signed URL rather than a permanent public one. That is a pattern rather than a standard, but it puts the ownership check in the one place your application controls.
When a single application serves many customer organizations, this stops being an object-ownership question and becomes an architectural one, which is why multi-tenant architecture treats tenant isolation as a data-layer decision rather than a controller check.
Insecure design slid from fourth to sixth on the 2025 list, and OWASP's stated reason is that security misconfiguration and supply chain failures leapfrogged it rather than that it got safer. OWASP does also report noticeable industry improvement in threat modeling alongside that move.
Either way, threat modeling stays the cheapest security work available, because it happens before any code exists.
You do not need a formal methodology for a first pass. You need an hour, a whiteboard and the discipline to write down what you decide.
Step four is the one that finds real problems, and step six is the one that keeps them found. A threat model nobody can locate is a meeting, not a control.
Authentication and authorization get discussed together and fail separately. Authentication decides who is making the request, and the industry has largely solved it. Authorization decides what that person may touch, and it is specific to your product.
Authentication failures held steady at number seven in 2025, and OWASP's own reading is that wider use of standardized frameworks is having a beneficial effect on how often these failures occur. The category covers 36 weakness types and was renamed from identification and authentication failures to reflect that scope.
The practical conclusion is to stop writing this layer. Password hashing, reset flows, session rotation, lockout policy, multi-factor enrollment and recovery are all solved, and the solutions have been attacked for years longer than yours will be.
Use your framework's authentication package or a hosted identity provider, turn on multi-factor authentication for anything administrative, and keep sessions short enough that a stolen cookie expires before it is useful.
An authorization check that lives in one controller works until somebody adds a second controller. The checks that survive are the ones placed where every request has to pass through them.
Push the ownership condition down into the data access layer, so the query itself cannot return a record the current user has no claim to. Deny by default, so a new endpoint stays locked until somebody deliberately opens it. Then test the negative case, because a test proving a user can see their own data says nothing about whether they can see somebody else's.
Our work on iCopy's Nimbus platform made this concrete. The product retrieves medical records, so who may see which document was a requirement from the first week rather than a hardening pass bolted on later.
We also built a clickable prototype that served as both a foundation for the build and a sales asset, and a prototype is a cheap place to settle access rules while changing them still costs nothing.
Injection slipped from third to fifth while holding its position relative to cryptographic failures and insecure design, so what moved was the categories above it rather than injection itself. It is one of the most heavily tested categories, spans 38 weakness types, and carries the greatest number of published vulnerabilities of any OWASP category.
The two headline members behave very differently. OWASP characterizes cross-site scripting as high frequency and low impact, and SQL injection as low frequency and high impact. The CWE rankings say the same thing from the other direction, with scripting first and SQL injection second.
Defending both comes down to never building a command out of string concatenation. Use parameterized queries or an ORM that parameterizes for you, encode output at the point you render it rather than when you store it, and validate input against what you expect instead of trying to blocklist what you fear.
Validation is also where the honest limits of a library show. A framework will stop a quote mark reaching your database, and it will cheerfully store a well-formed number your business rules should have rejected.
Both checks are yours, and the boundary between them is worth settling at design time rather than in review, which is one of the API design principles that saves the most argument later.
Software supply chain failures entered at number three in 2025, expanded from what used to be the vulnerable and outdated components category. The scope now covers compromises anywhere in the ecosystem of dependencies, build systems and distribution infrastructure, and it was voted a top concern in OWASP's community survey.
The data on it is the part worth sitting with. The category has only five weakness types and the fewest occurrences in the collected data, which OWASP attributes to how hard it is to test for. It also carries the highest average exploit and impact scores from published vulnerabilities of any category on the list.
On the two measures OWASP publishes, this category sits at opposite extremes.
So this is the lowest-frequency, highest-severity risk you carry, and the work is routine. Commit your lockfiles so builds are reproducible. Keep an inventory of what you actually ship. Turn on automated dependency updates and treat the resulting pull requests as real work rather than noise.
Pin your build tooling as carefully as your runtime libraries, since a compromised build step reaches everything. Patch cadence beats patch perfection here: a codebase updated monthly is in a very different position from one updated when something breaks, and the gap compounds, which is the argument for treating shipped software as unfinished.
Security misconfiguration climbed from fifth in 2021 to second in 2025, appearing in 3.00% of applications tested across 16 weakness types. OWASP's explanation is that more of an application's behavior is now determined by configuration rather than code, so more of the risk moved there too.
This is the cheapest category to fix and the easiest to regress. Every item below is a setting rather than a rewrite, and every one of them ships broken often enough to be worth checking on a schedule.
An internal tool is not exempt because it is internal. A custom CRM holds the same customer records your public application does, and it usually ships with looser configuration because nobody expects a stranger to reach it.
Logging and alerting failures held at number nine, with a deliberate rename from monitoring to alerting. OWASP's reasoning is blunt and worth quoting: great logging with no alerting is of minimal value in identifying security incidents.
That describes a fair number of the systems we are asked to review. Logs exist, they are retained, and nobody has ever been woken up by one.
Fixing it starts with deciding which events deserve an alert rather than which events deserve recording. Repeated authorization denials for one account, a successful login from a new country followed by a permission change, a spike in 403 responses on one endpoint, and any write to your own user or role tables are all small in volume and high in signal.
Four events against everything else you keep is the whole of the arrangement.
Log plenty, alert on little, and make sure the alert reaches a person with the access to act on it.
Web application security tooling splits into categories that each answer a narrow question, and the common mistake is buying the wrong one for the risk you carry.
| Tool type | What it genuinely finds | What it will miss |
|---|---|---|
| SAST (static analysis) | Unparameterized queries, unsafe deserialization, hardcoded secrets | Whether a user is allowed to see a record |
| SCA (dependency scanning) | Known vulnerabilities in libraries you ship | A compromised build step, or an unused dependency's real risk |
| DAST (dynamic scanning) | Reflected scripting, missing headers, exposed endpoints | Business logic reachable only after a specific sequence of actions |
| WAF | Generic attack patterns in traffic | Anything that looks like a legitimate authenticated request |
| Manual penetration test | Chained logic flaws, authorization gaps, undocumented assumptions | Whatever changes the week after it finishes |
Read down the right-hand column and the gap is consistent. Automated tools find properties of code and traffic, and they do not find broken business rules.
Since broken business rules are what tops the OWASP list, the manual review is the one with no substitute. A penetration test before a launch handling sensitive data is worth its cost, and it is worth scoping against your own threat model rather than letting the tester guess what matters.
We do not run penetration tests ourselves, and the part we do take on is the scope that goes to the firm that does: which endpoints carry the data that would actually hurt, which roles should never be able to reach each other, and which business rules a tester would otherwise have to infer from the UI. If you want help deciding what to put in that scope, contact us.
The riskiest moment for a web application is a change of ownership: a contractor finishing, an engineer leaving, or a codebase arriving from another team. Controls that depended on somebody remembering them stop working, and nobody notices for months.
A handover review is a short, specific exercise rather than a full audit. Confirm who still holds production credentials and remove the ones that should not exist. Walk the authorization rules with whoever is leaving while they can still explain them. Check that the dependency update process has an owner by name, and confirm the alerts route to somebody currently employed.
This is the same discipline a buyer applies during technical due diligence long before any money moves, and the reviews that go worst are the ones where the original team left without that conversation.
If you do one thing this week, take your three most sensitive endpoints and try to read another account's data through them by editing identifiers. That single test exercises the category sitting at number one on the OWASP list, needs no budget, and tells you something true about your application in an afternoon.
Securing web applications well is mostly a matter of doing a small number of unglamorous things reliably. After that first test, work down the OWASP list, which has already weighed impact against frequency for you.
Lock down configuration, get dependency updates on a schedule, and set up a handful of alerts you would genuinely act on. Buy tools once you know which question you are asking.
We work with teams building and scaling web applications where the data is the product, and most of the web application security work we do early is not exotic. It is a missing ownership check, a dependency nobody updated since launch, and a log file nobody reads. Our development team tends to find all three in the same first week.
It covers the application's own layer, meaning its code, data model, sessions, dependencies and the configuration they run under. What separates it from network or endpoint security is that the logic being defended is logic you wrote, so generic tooling can only take you part of the way. OWASP's Top 10 and MITRE's CWE Top 25 are the two reference lists most teams work from.
Broken access control leads the OWASP Top 10 for 2025, followed by security misconfiguration and software supply chain failures. On MITRE's 2025 CWE Top 25, cross-site scripting ranks first and SQL injection second, drawn from 39,080 published vulnerability records. The lists differ because one ranks risk categories and the other ranks individual weakness types, so reading both gives a fuller picture than either alone.
A useful checklist follows the order in which decisions get made rather than a severity ranking. Start with a threat model naming your sensitive data and trust boundaries, then authentication handled by a standard library, authorization enforced in the data layer with deny-by-default, and parameterized queries throughout.
After that comes dependency updates on a schedule, hardened configuration, and alerts on a small set of high-signal events. Finish with a handover step covering credentials and rule ownership, since that is where controls quietly lapse.
Dependency scanning usually pays back first, because it is cheap, automatable and aimed at the category with the highest average impact scores. Static analysis is worth adding once your codebase is large enough that nobody reads every pull request closely. A manual penetration test is the only option that reliably finds broken business rules, so it belongs before a launch handling sensitive data rather than as an annual habit.
Small teams do best by narrowing the surface they own. Use a standard authentication package instead of writing one, lean on managed services whose configuration is audited for you, and reserve your own effort for authorization rules and input validation, which are specific to your product and cannot be handed to a library. One scheduled hour a month on dependency updates and configuration review covers most of what a part-time security role would otherwise do.
Most security problems we find in existing codebases are ordinary and fixable, and they are easier to deal with before a customer, an auditor or an acquirer finds them first.
If you want a second pair of eyes on how your application handles access, data and dependencies, contact us. The first thing we ask for is a list of the endpoints that worry you most.
