The OSBR Handbook
Sign in

Application Security

This is the standard the Quality Gate's Security lens holds work to for the running application. It is the application-layer complement to the Security Policy: where that policy governs device and account conduct — how developers work, how they hold credentials — this page starts at the first line of request-handling code and follows it through to the logged response. It answers two questions together: is each control correct? and what still holds when a control fails? Deviations are allowed, but — as everywhere in the handbook — they must be deliberate and justified in the project's design notes.

Like the rest of OSBR's engineering guidance, this leans on standards that already exist rather than inventing a house security model. OSBR adopts the OWASP Application Security Verification Standard (ASVS) as its application-layer baseline (§1), and grounds the practices below in the OWASP Top 10, the OWASP Proactive Controls, the Cheat Sheet Series, the CWE Top 25, and NIST SSDF (SP 800-218). We adopt their criteria and right-size them for an SME — we do not adopt the headcount or infrastructure behind their reference setups.

Application security is where OSBR's values hold a wall. Be Nice to the operator paged at 3am: an app that fails closed, leaks nothing, and logs what happened is a far kinder thing to debug than one that fails open and silently. Be Kind to the users whose data lives behind that boundary and to the next engineer — human or AI — who extends the code: secure-by-default helpers are defences they inherit rather than re-derive, and no user ever agreed to bet their data on our getting a single regex or token check exactly right. Be Strong on the boundary, and hold more than one: an attacker only has to win once, so we plan to lose a layer and keep the breach contained rather than catastrophic. AI agents increasingly both call these applications and write their request-handling code — and neither can be trusted to infer an unwritten convention, which is why the defence has to live in the framework and the shared helpers, not in one developer's head.

How to read this policy

1. Goal

Every OSBR application is secure by default at runtime, and every important asset is reachable only through multiple independent boundaries that each start closed. No single control — no one firewall rule, auth check, input filter, or output encoder — is the only thing between an attacker and the data; when one layer fails, the next, on a different lineage, still holds. Concretely, an OSBR application meets this policy when:

This is the Swiss-cheese model: each layer has holes, but if the layers are independent the holes rarely line up, and a threat only passes when a hole in every slice aligns. Our job is to keep the slices independent so the holes stay misaligned — the defence-in-depth arrangement NIST and the NSA have advocated for decades precisely because no single safeguard is ever perfect.

2. Responsibility

This page governs the application. The Security Policy still governs the developer and the account; the two are read together.

3. Practices

3-1. Verify against OWASP ASVS — choose a level

ASVS is a catalogue of testable requirements, organised into three ascending assurance levels. We use it as the yardstick and the audit checklist.

Rules:

Use the OWASP Top 10 and the CWE Top 25 to understand what goes wrong and why; use ASVS to verify you closed it; use the Cheat Sheet Series for the how-to on each control.

3-2. Build on the OWASP Proactive Controls

The Proactive Controls are the positive, build-time counterpart to the Top 10's list of failures — the techniques applied by default. They frame the rest of this section: define security requirements as ASVS levels (§1); leverage vetted frameworks and libraries rather than hand-rolling crypto, session handling, or output encoding (hand-rolled security is the single most common source of the bugs this page prevents); validate all input (§3-8); encode and escape output (§3-9); secure database access (§3-10); implement digital identity (§3-6, §3-7); enforce access controls (§3-11); protect data everywhere; and handle all errors and log security events (§3-14, §3-15). This maps onto NIST SSDF practice group PW (Produce Well-Secured Software) — standardised, vetted components and secure-by-default settings over bespoke security code — with our CI gate and AI-automated review acting as the SSDF PW.7/PW.8 review-and-test practices.

3-3. Start closed: restrictive defaults, fail-secure

Every boundary MUST default to the safe state and open only by explicit, recorded decision. A protection you must remember to enable is off in every place someone forgot; a protection on by default is off only where someone deliberately — and, under §3-16, visibly — turned it off. Defaults decide the security of the code nobody reviewed closely.

3-4. Layer independent boundaries

An important asset MUST be reachable only through multiple boundaries, so that breaching one is not breaching all — and the layers only add up if they fail independently.

This is the layered complement to our Zero Trust posture (NIST SP 800-207, "assume breach"). Zero Trust tells us to distrust every request; defence in depth tells us to distrust every control. A verified request that slips one check must still meet the next.

3-5. Contain the blast radius

Because we assume a layer will fall, we design so the fall is survivable.

3-6. Authentication

Authentication proves who is calling; getting it wrong is Top 10 A07 (Identification and Authentication Failures).

3-7. Session management

Once authenticated, the session is the credential — the thing an attacker wants to steal or fixate.

3-8. Input validation

All input from any trust boundary is untrusted — request bodies, query and path parameters, headers, cookies, file uploads, webhook payloads, and responses from upstream services.

3-9. Output encoding

Injection is ultimately an output problem: data crosses into an interpreter (HTML, SQL, a shell, a URL) that mis-reads it as code. Encode/escape data for the specific sink it is written to, at the moment of output.

3-10. Injection defences (SQLi, XSS, CSRF, SSRF, command/template)

Top 10 A03 (Injection) is a class, not a single bug. Each variant has a standard, non-negotiable defence — use it, do not improvise.

3-11. Access-control enforcement (authorization)

Top 10 A01 (Broken Access Control) is the #1 web application risk. Authentication says who you are; access control says what you may do — and it is checked far too often on the client, or not at all. This is the server-side enforcement of the deny-by-default rule in §3-3, and it also anchors the Access Control standard.

3-12. Secrets handling at runtime

The Security Policy already forbids committing credentials and long-lived high-privilege keys. This is the runtime counterpart — how the live app holds and uses secrets — and part of the broader Data Protection standard.

3-13. Secure defaults

Top 10 A05 (Security Misconfiguration): the app is only as safe as its least-safe default. Secure-by-default (a NIST SSDF principle and a CISA Secure-by-Design tenet) means the safe configuration is the one you get without opting in — the concrete extension of §3-3.

3-14. Error handling that doesn't leak internals

How an app fails is a security property. A leaked stack trace, SQL error, or internal path is reconnaissance handed to an attacker (CWE-209).

3-15. Security logging and monitoring

Top 10 A09 (Security Logging and Monitoring Failures): an attack you cannot see is an attack you cannot stop or explain afterwards.

3-16. Record every deliberate relaxation

Layers and defaults will sometimes be relaxed for a real reason. That is allowed — silently relaxing them is not. An undocumented exception is indistinguishable from a bug, so every relaxation MUST be recorded so the set of deliberately-open holes is always known.

4. Anti-patterns

The failure modes this policy exists to prevent:

References

Named standards and practice this policy draws on, chosen because they are published, testable, and adoptable by a small team.

Verification standard (adopted)

Risk catalogues — the "what goes wrong"

Positive controls & how-to

Defence in depth & layered controls

Zero Trust, least privilege & fail-secure

Process & secure-by-default

Related OSBR standards