Application Security

TLS protects data crossing the network. Authentication establishes who the caller is. Both can be flawless while your application hands an attacker the entire user table, because the attacker is not intercepting anything — they are a properly authenticated user sending a request you did not expect.

Application security is the discipline of assuming every byte arriving from a client is hostile, and building so that hostility cannot change what your code does. Almost every vulnerability below is one idea in different costumes: data supplied by a user escaped its lane and became instructions.

There is a hierarchy of fixes, and it matters more than any individual attack. Structural fixes make the class of bug impossible — a parameterised query cannot be injected regardless of the input. Filtering fixes try to spot bad input, and they lose eventually, because you are guessing at an infinite set. Prefer structure. Filter only as an extra layer.

Injection: separate code from data

An injection bug happens when user input is concatenated into something an interpreter parses — SQL, a shell command, an LDAP filter, a template.

// Every value of `email` is potentially a fragment of your query
db.query(`SELECT * FROM users WHERE email = '${email}'`);

Supply ' OR '1'='1 and the query returns every row. The interpreter has no way to know which characters you intended as data, because by the time it sees the string that distinction has already been destroyed. Parameterised queries restore it:

db.query('SELECT * FROM users WHERE email = ?', [email]);

The query text and the values travel separately. The database plans the statement first and binds the value afterwards, so the value can contain any characters at all and will never be parsed as syntax. This is not an escaping technique that works well; it is a structural change that makes the bug impossible. The same reasoning applies to the shell. Never build a command string from input; invoke the binary directly with an argument array, so there is no shell to interpret metacharacters. If you find yourself writing an escaping function for shell arguments, you have chosen the losing branch.

Cross-site scripting: encode on output

XSS is injection where the interpreter is the browser. Attacker-supplied text ends up in your page and executes as script in your users' sessions, with all their privileges.

• Stored. The payload is saved — a comment, a display name, a support ticket — and served to everyone who views it. The most damaging variety, because it needs no interaction from the victim.
• Reflected. The payload rides in a URL or form field and is echoed back in the response. Requires the victim to follow a crafted link.
• DOM-based. No server involvement at all. Client code takes something from the URL fragment or postMessage and writes it into the page.

The instinct is to sanitise on input: strip <script> tags as data arrives. This fails twice over. The blocklist is unwinnable — event handlers, javascript: URLs, encoded variants, SVG, and whatever browser vendors ship next. More fundamentally, safety is a property of the destination, not the value: the same string is harmless in a JSON response, dangerous in HTML, dangerous differently inside a <script> block, and dangerous differently again in an attribute or a URL. So encode on output, contextually, at the moment of rendering. Modern templating and UI frameworks do this by default, which is why XSS has become rarer — and why the remaining cases cluster around the APIs that deliberately bypass it, the ones named something like "dangerously set inner HTML". Every use of those is a decision requiring justification, and if the content genuinely must be rich text, run it through a real sanitiser library rather than a regular expression you wrote.

CSRF, and what SameSite changed

Cross-site request forgery exploits the browser's helpfulness: cookies for your domain are attached to requests regardless of which site initiated them. An attacker's page can submit a form to your bank endpoint, and the victim's session cookie rides along.

The historical defence is the synchroniser token — a random value your server issues and requires back in the request body or a header. The attacker's page cannot read it, because the same-origin policy stops them reading your responses.

SameSite cookies changed the picture: a cookie marked SameSite=Lax is not sent on cross-site POST requests at all, which removes the class of attack at the browser level, and Lax is now the default in major browsers. That is a genuine structural improvement — but not a complete answer, and the nuances are what get tested:

• Lax still permits top-level GET navigations. Any state-changing endpoint reachable by GET remains exploitable. State changes belong on POST, PUT, PATCH and DELETE — which was already the rule.
• Subdomains are same-site. An XSS or a takeover on a neglected subdomain sits inside your protection.
• Token-in-header APIs are not affected, because an Authorization header is not attached automatically by the browser. CSRF is a cookie-authentication problem specifically.

Keep synchroniser tokens for cookie-authenticated state changes, and treat SameSite as the strong second layer that it is.

SSRF: the one the cloud made critical

Server-side request forgery is the vulnerability people still miss, and it became severe when applications moved onto infrastructure that exposes credentials over HTTP. The shape is innocent: your application takes a URL from a user — import an image, register a webhook, generate a link preview — and requests it from the server. The attacker supplies a URL that is not on the internet. Internal admin panels with no authentication because "they are only reachable internally". Databases and caches bound to a private interface. And above all, the cloud instance metadata endpoint, a link-local address that answers unauthenticated HTTP requests from the instance itself and will happily return the machine's role credentials. One naive fetch of a user-supplied URL becomes credentials for your account.

Defences, in order of strength:

• Do not fetch user-supplied URLs at all if the feature can be built another way.
• Allow-list destinations. A webhook feature can require pre-registered, verified hosts.
• Resolve the hostname yourself and reject private, loopback, link-local and reserved address ranges before connecting — then connect to the resolved address, because otherwise a hostname can resolve to a public address during your check and a private one during the fetch.
• Disable redirect following, or re-validate the target on every hop. Redirects are the standard bypass for a naive check.
• Egress network policy. The strongest control, because it does not depend on your code being correct: the service that fetches user URLs should have no route to internal ranges or the metadata endpoint.

Broken object-level authorisation

The most common serious vulnerability in real APIs, and one scanners almost never find.

GET /api/invoices/8213

You authenticated the caller. You checked they have the invoices:read permission. You never checked that invoice 8213 belongs to them. The attacker changes the number and reads someone else's invoice — no exploit, no payload, just arithmetic. When identifiers are sequential integers, the whole table can be enumerated in a loop.

The classic advice is to use unguessable identifiers. It is worth doing, but it is obscurity rather than a fix, and it fails the moment an identifier appears in a shared URL, a log or an export. The real fix is to make ownership part of every data access, structurally, so forgetting it is not possible:

// Wrong: authorise after fetching, or not at all
const invoice = await invoices.findById(id);

// Right: the caller's scope is part of the query
const invoice = await invoices.findOne({ id, organisationId: user.orgId });

Enforce this in one place — a repository that requires a tenant scope, a policy layer every handler must call, a middleware that resolves the resource and checks it before the handler runs. A convention that every developer must remember on every endpoint will be broken by the fortieth endpoint. Make the safe path the only path.

Mass assignment

A close relative. Your update handler binds the request body straight onto an entity:

Object.assign(user, req.body);   // convenient, and a privilege escalation
await user.save();

The client sends { "name": "Ada", "role": "admin" }, or accountBalance, or emailVerified, and every writable field on your model just became a public API. The fix is the DTO discipline from low-level design: define exactly which fields this endpoint accepts, validate them, copy only those. Allow-list, never blocklist — a blocklist forgets the sensitive field somebody adds next quarter, and that omission is silent.

Secrets and dependencies

Nothing sensitive belongs in a repository. Not API keys, not database passwords, not signing keys, not a .env committed "temporarily". Git remembers: deleting the file in a later commit leaves the value in history, and public repositories are scraped for keys within minutes of a push. If a secret is committed, the only remediation is to rotate it — cleaning history is housekeeping, not a fix. Secrets belong in a managed store or the platform's injected environment, scoped narrowly and rotated on a schedule, with automated scanning in the pipeline so the mistake is caught before it merges.

Your dependency tree is your attack surface. Most of the code you ship, you did not write and have not read. Three practices carry the weight: keep a lockfile so builds are reproducible, run vulnerability scanning on every build so a known issue in a transitive dependency surfaces immediately, and treat adding a dependency as a decision — the smallest, least-audited packages are exactly the ones taken over.

Security headers: defence in depth

Headers do not fix bugs. They reduce the impact of the bug you have not found yet, which is the correct thing to expect of them.

CSP is the one worth real effort, and the one most often disabled by its own configuration: a policy containing unsafe-inline for scripts permits exactly what CSP exists to prevent. Deploy it in report-only mode first, fix what it flags, then enforce.

Check your understanding

Common mistakes

Validating only in the client. The browser is a convenience, not a control. Anyone can send the request directly.

Sanitising input instead of encoding output. Safety depends on the destination context, which input-time filtering cannot know.

Authenticating without authorising the object. Knowing who the caller is says nothing about whether this row is theirs.

Binding request bodies straight onto entities. Every writable field becomes public, and blocklists forget the field added next quarter. Use allow-listed DTOs.

Trusting internal networks. SSRF, a compromised dependency and a rogue subdomain all originate inside the perimeter.

Leaking detail in errors. Stack traces and database messages hand attackers your schema. Log the detail, return a generic message and a reference id.

Practice

Key takeaways

• The recurring theme is data escaping its lane and becoming instructions — and the recurring fix is structural, not filtering.
• Parameterised queries and argument-array process invocation make injection impossible rather than unlikely.
• Defeat XSS by encoding on output for the specific context; input sanitisation cannot know where the value will land.
• SameSite cookies remove most CSRF, but state changes must never be GETs, and subdomains count as same-site.
• SSRF is the cloud-era miss: resolve and reject private, loopback and link-local addresses, refuse redirects, and block egress at the network.
• Broken object-level authorisation is the most common real API vulnerability. Put the caller's scope inside the query and test as two tenants.
• Use allow-listed DTOs to stop mass assignment, keep secrets out of repositories, and rotate anything committed.
• Treat security headers and CSP as impact reduction for the bug you have not found yet — never as the fix.

Further reading

• OWASP, Top 10 Web Application Security Risks (2021) — broken access control, injection and SSRF.
• OWASP, Cheat Sheet Series — query parameterisation, output encoding and SSRF prevention.
• Barth, Jackson and Mitchell, "Robust Defenses for Cross-Site Request Forgery" (CCS 2008).
• Orange Tsai, "A New Era of SSRF" (Black Hat USA, 2017) — cloud metadata as the escalation path.
• Michal Zalewski, The Tangled Web (No Starch Press, 2011) — browser security model and output contexts.