Skip to content
sec/atlas
knowledge base · owasp top 10

The OWASP Top 10, in code.

Each of the ten web risks explained, with vulnerable and fixed code in several languages, and the test that proves the fix.

$ click a card for details · ctrl+k to search

learning map

Topics are laid out by level, from foundations to advanced. Arrows point from a prerequisite to what builds on it. Select a topic to preview it, or follow the highlighted next step.

Your next step

0 of 10 studied
start this topic

01 Foundations

The ideas everything else builds on.

02 Practitioner

Apply the controls and make them work in practice.

03 Advanced

Design, scale and operate at depth.

  • studied
  • ready to study
  • prerequisites missing

where each risk is decided

From design to operations: every risk has a phase where prevention is cheap. Each chip opens the matching topic.

  1. 01design

    decide what must be impossible

    threat models and abuse caseswho may do what, on every requestsecurity requirements (ASVS)

    gate: every feature has abuse cases and an authorization rule before code

  2. 02code

    handle input, secrets and identity safely

    keep data away from instructionsprotect data at rest and in transitprove who the user is

    gate: dangerous patterns are blocked in review and CI

  3. 03ship

    deliver verified code with safe settings

    know and lock what you depend onverify what you runhardened, scanned configuration

    gate: only signed, scanned, hardened artifacts reach production

  4. 04operate

    see attacks and fail safely

    logs that become alertserrors that deny, not leakrunbooks and response

    gate: an attack is noticed, contained and leaves a trail

topics

A01 Broken Access Control
Authentication says who you are; access control says what you may do. When the server forgets to check on every request, changing an id in a URL is all an attacker needs.
technique· stage: design
A02 Security Misconfiguration
Defaults are built for convenience, not for the internet. A debug flag, an open bucket, a verbose error or a default password turns correct code into an incident.
practice· stage: ship
A03 Software Supply Chain Failures
Your application is mostly other people's code. A vulnerable library, a malicious package, or a tampered build step reaches production with your name on it.
practice· stage: ship
A04 Cryptographic Failures
Encryption is rarely broken; it is skipped, misconfigured or misused. Plain-text transport, fast password hashes and hard-coded keys are how data actually leaks.
technique· stage: code
A05 Injection
When data and instructions travel in the same string, whoever controls the data controls the instruction. The cure is to keep them apart, in every language.
technique· stage: code
A06 Insecure Design
A perfect implementation of a bad design is still a vulnerability. Security has to be asked for before the first line of code, as a requirement, not found afterwards as a bug.
concept· stage: design
A07 Authentication Failures
Login is the front door. Unlimited guesses, reused passwords, sessions that never expire and tokens that are not really verified all let an attacker walk in as a real user.
technique· stage: code
A08 Software or Data Integrity Failures
If the program accepts updates, plugins, serialized objects or pipeline output without proving where they came from, whoever can alter them can run code as you.
technique· stage: ship
A09 Security Logging and Alerting Failures
You cannot respond to what you cannot see. Logs without alerts are an archive; alerts without good logs are noise. Both must exist, and neither may be injectable or full of secrets.
practice· stage: operate
A10 Mishandling of Exceptional Conditions
Security often depends on what happens when something goes wrong. If an error means "allow", a stack trace means "here is my code", or a half-finished operation means "corrupted state", the failure path is the vulnerability.
technique· stage: operate