Application security playbook

An application security playbook for any website, API or app with a server. It lists the controls you build in, so that common attacks fail. Each rule says what to build, how to build it and how to check that it holds.

The rules follow the OWASP Application Security Verification Standard (ASVS) 5.0. The ASVS 5.0 mapping names the ASVS requirements behind each rule. Pick a target level first, as Pick an ASVS level for each app says. Most business apps aim for level 2.

This playbook owns the controls. The Adversarial testing playbook holds the attacks that prove each control holds, with the rules for testing safely. Sign-up, sign-in methods, recovery and roles live in the Accounts and identity playbook, and the Infrastructure playbook covers cloud access and networks.

Chapters

1. Threat modelling

   Draw how data flows and mark where trust changes. List what could go wrong at each step, and turn each threat into a test before you build.

   • Recommended 5

2. Input and injection

   Keep data and code apart. Untrusted input must never become part of a query, a page, a shell command, a template, a file or a header.

   • Required 7
   • Recommended 4

3. Authentication and sessions

   Slow down guessing, store passwords safely, verify every token and keep session cookies locked to your own site and to the signed-in person.

   • Required 8
   • Recommended 2

4. Access control

   Check on the server, on every request, who is asking and what they may touch. Deny by default and decide access in one place for every route.

   • Required 2
   • Recommended 2

5. Browser security headers

   HTTPS, a strict Content Security Policy, isolation headers, integrity checks and origin checks that keep the browser from turning against visitors.

   • Required 2
   • Recommended 15
   • Optional 1
   • Avoid 1

6. Requests, files and caches

   Stop the server fetching addresses an attacker picks, check every uploaded file, keep paths in their folder and keep private replies out of caches.

   • Required 4
   • Recommended 4

7. Limits and business logic

   Limit how fast and how much anyone can ask for. Check every price, step and count on the server, so each change happens exactly once.

   • Required 5

8. Cryptography and keys

   Encrypt every connection and stored secret with standard algorithms, keep keys in a key service, renew certificates by machine and plan for quantum.

   • Required 2
   • Recommended 6

9. Secrets and configuration

   Keep keys out of code and pages and give each key the least power. Close debug doors and hidden files, and keep servers current and quiet.

   • Required 4
   • Recommended 5

10. Supply chain

    Most attacks walk in through someone else's code. Lock, review and wait for new packages, publish what each release holds and verify what you install.

    • Required 2
    • Recommended 10

11. Errors, logs and vulnerabilities

    Show short errors and log attacks without personal data. Publish how to report a hole, fix each one in time and know what to do in a breach.

    • Recommended 6

12. AI features and agents

    Controls for the AI features you build. Enforce limits outside the model, keep private data, outside content and a way out apart, and sandbox code.

    • Required 3
    • Recommended 8

Evidence

• ASVS 5.0 mapping

  Each rule in this playbook mapped to the OWASP Application Security Verification Standard 5.0 requirements it helps you meet, chapter by chapter.

All 108 rules on one page

This is a lot to check. An Expert can check it for you.

Related playbooks

• Rules of engagement

  In the Adversarial testing playbook. Prove each control holds by attacking a staging copy, with written permission and a scope file.

• Sign-in methods

  In the Accounts and identity playbook. Passkeys, passwords and single sign-on decide how people prove who they are. This playbook covers the checks behind them.

• Identity and access

  In the Infrastructure and environments playbook. Cloud roles, short-lived credentials and networks keep a leaked key or a broken server from reaching everything else.

• API security

  In the API design playbook. Authentication, scopes and rate limits for every endpoint, in the shape API clients expect.

• Breaches and reporting

  In the Compliance and governance playbook. When a control fails, the reporting clocks start. Know who to tell and by when.