Application Security: The Most Common Issues We Find in Real Projects

Most security incidents in commercial web projects do not come from a novel attack — they come from a handful of well-known mistakes that keep recurring because they are easy to introduce and easy to overlook in review. This is the list we actually find during audits, roughly ordered by how often we see each one.

Where most real issues come from

1. Broken access control

The single most common finding in real audits: an API endpoint checks that a user is logged in, but not that they own the resource they are requesting. Every authorization check has to happen server-side, on every request — a hidden button or a disabled UI element is not a security control, only a UX one.

2. Injection

Still on the OWASP Top 10 after two decades because string-concatenated queries keep getting written under time pressure. Parameterized queries and an ORM that escapes by default eliminate this category almost entirely — the fix is not vigilance, it is tooling that makes the unsafe pattern harder to write than the safe one.

3. Cross-site scripting (XSS)

Modern frameworks (React, Vue) escape output by default, which has quietly eliminated most classic XSS — until a developer reaches for `dangerouslySetInnerHTML` or `v-html` for a rich-text field and reintroduces the exact hole the framework was preventing. Any raw HTML rendering needs a sanitization library, not trust in the source.

4. Secrets in client code or version control

API keys and tokens committed to a repo, or bundled into client-side JavaScript where anyone can read them from devtools, is a recurring finding even on otherwise well-run projects. Secrets belong in environment variables on the server, never in anything shipped to the browser or committed to git — and a leaked secret needs immediate rotation, not just removal from the latest commit.

5. Outdated dependencies with known vulnerabilities

A vulnerable transitive dependency three levels deep is invisible without tooling and routine review. Automated dependency scanning (Dependabot, npm audit, or equivalent) in CI, with a real process for triaging and patching what it finds, closes most of this gap — leaving it unmonitored is the actual failure, not any single vulnerable package.

6. Insecure direct object references (IDOR)

Trusting a client-supplied ID (`/api/invoices/1234`) without verifying the requesting user actually owns that resource lets an attacker simply increment the number. Every resource-fetching endpoint needs an ownership or permission check, not just an authentication check.

What actually prevents these

1. Authorization checks on every server-side request — never inferred from the UI.
2. Parameterized queries and an ORM by default; raw query strings as a reviewed exception, not the norm.
3. A sanitization library for any raw HTML rendering, with framework auto-escaping left on everywhere else.
4. Secrets only in server-side environment variables, never in client bundles or git history.
5. Automated dependency scanning wired into CI, with an actual triage process for what it flags.
6. Security review as a normal part of code review for anything touching auth, data access, or user input — not a separate audit done once.

The bottom line

Application security is mostly discipline around a known, short list of recurring mistakes — not a constant arms race against novel threats. The fixes are largely process and tooling (parameterized queries, dependency scanning, server-side authorization) rather than heroics, which is exactly why they belong in the default engineering process on every engagement, not bolted on before a compliance audit.