cheatsheetseries.owasp.org

What is the OWASP Cheat Sheet Series?

The OWASP Cheat Sheet Series is a free, community-maintained collection of concise security guidance documents. Each "cheat sheet" tackles one specific topic — such as SQL injection prevention, password storage, or cross-site scripting defense — and distills it into practical rules a developer or reviewer can apply directly. The site is essentially an index: you pick the sheet matching your technology or risk, rather than reading it start to finish.

Who it's for and how it's used

• Developers who need a concrete "do this, not that" reference while writing authentication, file upload, or session code.
• Security reviewers and architects checking a design against established practice.
• Teams building a secure coding checklist or onboarding material from individual sheets.

The collection is broad rather than deep. You'll find sheets organized by language and framework (Java, Django, Node.js, Laravel, Ruby on Rails), by vulnerability class (injection, CSRF, SSRF, deserialization), and by architecture topic (microservices, multi-tenant security, secrets management). Several index views — alphabetical, ASVS, MASVS, Proactive Controls, and Top 10 — let you navigate by standard instead of by name.

Trade-offs to keep in mind

Cheat sheets are deliberately short, so they give you the rule and the reasoning but not a full threat model or a tutorial. They also assume you already know the underlying technology. Treat them as a checklist and a starting point, then follow the references inside a sheet when you need depth. Because the project is community-edited, quality and currency vary by topic; check that a sheet still reflects the versions you actually run.

A practical next step

If you're starting a review, pick the index that matches your framework: go to the alphabetical index, find your stack (for example, Django Security or Node.js Security), and read the two or three sheets covering the areas you're touching. For a structured audit, the ASVS index maps sheets to verifiable requirements, which is more useful than browsing by title.

The project lives at OWASP Cheat Sheet Series, and the wider organization's material is at OWASP.

How can I use the OWASP Cheat Sheet Series to improve my application's security?

Use the OWASP Cheat Sheet Series as a topic-by-topic implementation reference, not as a single book to read end to end. Pick the sheets that match what your application actually does, turn their guidance into concrete tasks, and verify each one in code review or testing.

OWASP Cheat Sheet Series

H3 Practical ways to use it

• Start from your stack and features. The index groups sheets by language, framework and concern, so you can go straight to entries like Django Security, NodeJS Security, Java Security or Laravel rather than reading generic advice.
• Cover the common failure modes first. Sheets such as Cross Site Scripting Prevention, SQL Injection Prevention, Cross-Site Request Forgery Prevention, Authentication and Authorization address issues that affect most web applications.
• Use it during design, not only after a finding. Sheets on Attack Surface Analysis, Secure Product Design, Threat Modeling-adjacent topics and Authorization Patterns help you make decisions before code exists.
• Turn a sheet into a checklist for pull requests. For example, use Input Validation and Query Parameterization as review criteria for any code that handles user-supplied data.
• Match sheets to modern components. If you use containers, CI/CD, APIs or AI features, there are dedicated sheets for Docker Security, CI CD Security, REST Security, GraphQL, LLM Prompt Injection Prevention and AI Agent Security.

H3 A concrete starting scenario

Suppose you maintain a Django app with a REST API, file uploads and a login system. A focused first pass might be:

1. Django Security and REST Security for framework-level configuration.
2. Authentication, Password Storage and Multifactor Authentication for the login flow.
3. Authorization and Insecure Direct Object Reference Prevention for access checks on records.
4. File Upload and Input Validation for anything users submit.
5. Logging and Error Handling so failures are recorded without leaking internals.

Each sheet gives you specific controls; your job is to decide which apply and how to test them.

H3 How to choose what to read

H3 Trade-offs to keep in mind

The series is broad and detailed, so trying to apply every sheet at once leads to shallow compliance rather than real improvement. Sheets are guidance, not a substitute for testing your own system, and some topics overlap or assume context that may not match your architecture. Treat each sheet as a starting point, adapt recommendations to your risk profile, and record where you deliberately deviate.

Next step: open the alphabetical or topical index, list the five sheets most relevant to your application, and convert each into two or three verifiable tasks with an owner and a test.

Which cheat sheet should I consult for preventing SQL injection?

Use the SQL Injection Prevention Cheat Sheet in the OWASP Cheat Sheet Series. It is the page in this collection dedicated to that exact problem, and it sits alongside related sheets such as Query Parameterization and Injection Prevention in Java if you need language-specific guidance.

A practical way to use it: start with the SQL Injection Prevention sheet for the core rules, then open the sheet for your stack (for example Java, .NET, Django, Rails or Node.js) to see how those rules map to your framework's database APIs and query builders. If you are reviewing an existing codebase rather than writing new code, pair it with the Secure Code Review sheet so you have a checklist for spotting string-concatenated queries and unsafe dynamic SQL.

Browse the full set at OWASP Cheat Sheet Series.

What are the best practices for securing a REST API according to OWASP?

OWASP's REST API security guidance centers on one idea: never trust the client, and enforce every rule on the server. The Cheat Sheet Series covers this in its REST Security and REST Assessment sheets, alongside topic sheets such as Authentication, Authorization, Input Validation, and JSON Web Token.

Core practices

• Use HTTPS everywhere. Reject plain HTTP and avoid redirects that leak credentials. Apply HSTS so clients cannot be downgraded.
• Authenticate with tokens, not sessions. OAuth 2.0 bearer tokens or signed JWTs are typical; validate signature, issuer, audience, and expiry on every request. Never accept a token the API itself did not verify.
• Authorize per resource, not per endpoint. Check that the caller may act on the specific object (this is the Insecure Direct Object Reference problem), and apply this consistently, including nested and bulk operations.
• Validate and constrain input. Use allowlists, schema validation, and strict typing. Query parameterization prevents injection in database calls; output encoding prevents it in responses.
• Set explicit HTTP headers. Content-Security-Policy, X-Content-Type-Options, and a restrictive CORS policy matter when browsers call the API. Avoid wildcard origins with credentials.
• Return minimal data and generic errors. Don't leak stack traces, internal IDs, or version details. Use consistent error shapes without revealing whether a username exists.
• Rate limit and monitor. Throttle by identity and IP to blunt credential stuffing and abuse, and log security-relevant events without recording secrets or full tokens.
• Manage secrets and keys properly. Rotate signing keys, keep them out of source control, and plan for algorithm changes (including post-quantum migration guidance).

Where to start

If you are auditing an existing API, work through the REST Assessment sheet as a checklist before reading the defensive sheets. For a new build, pick the sheets matching your stack — for example Django REST Framework, FastAPI Security, Laravel, or Node.js — since they translate the general rules into framework-specific configuration. The OWASP Cheat Sheet Series OWASP Cheat Sheet Series is the canonical index; the companion project OWASP hosts the API Security Top 10, which is useful for prioritising the risks above.

A practical decision rule: if a control can be bypassed by editing a request in a proxy, it belongs on the server. Client-side checks are usability aids, not security boundaries.

How do I implement authentication and authorization securely using OWASP guidelines?

Start with a clear split: authentication proves who the user is; authorization decides what that proven user may do. OWASP's Cheat Sheet Series treats them as separate design problems, and most real-world breaches come from confusing the two—or from checking identity once and then trusting the client for everything else. OWASP Cheat Sheet Series

Authentication: get the fundamentals right

The site's Authentication and Password Storage sheets are the core starting points. Practical steps:

• Store passwords with a modern, memory-hard hashing algorithm and a per-user salt; never reversible encryption.
• Offer multi-factor authentication, and prefer phishing-resistant methods such as passkeys where your user base supports them.
• Protect the login flow itself: rate-limit and lock out credential-stuffing attempts, use generic error messages, and secure the forgot-password path with single-use, expiring tokens.
• Manage sessions explicitly—rotate session identifiers on login, set sensible timeouts, and use secure cookie attributes.

The site also covers Multifactor Authentication, Credential Stuffing Prevention, Forgot Password and Session-related guidance as separate sheets, so you can go deep on whichever piece you are building.

Authorization: enforce it on the server, every time

The Authorization, Authorization Testing Automation and Insecure Direct Object Reference Prevention sheets are the relevant ones here. The recurring theme:

• Never rely on hidden UI elements or client-side checks; every request must be authorized server-side against the authenticated identity.
• Check authorization at the level of the specific object or record being accessed, not just the endpoint—this is exactly what IDOR prevention addresses.
• Centralize policy decisions rather than scattering ad hoc if user.role == admin checks across the codebase.
• Test authorization with automation, including regression tests, because permission bugs reappear easily as features change.

Where the two meet

Tokens and sessions are the bridge. The JSON Web Token, OAuth2 and SAML Security sheets cover how identity claims travel between systems. Treat any token as a credential: validate signatures, check expiry and audience, and avoid putting sensitive data in readable claims.

A useful next step: pick the two or three sheets matching your stack—for example, Authentication plus Authorization plus Insecure Direct Object Reference Prevention—and turn each recommendation into a checklist item in your code review. If you use a framework, the language-specific sheets (Django, Rails, Node.js, Java and similar) translate the same principles into concrete configuration.

What are the OWASP recommendations for securing a CI/CD pipeline?

For CI/CD, the OWASP Cheat Sheet Series points to its dedicated CI CD Security cheat sheet, which is where the project collects its concrete recommendations. Rather than one master rule, the guidance is a set of controls applied across the pipeline's stages: protecting the build environment, controlling who and what can change code, and limiting the damage if a step is compromised.

What the guidance generally emphasizes

• Keep secrets out of the pipeline. Prefer short-lived, scoped credentials from a secrets manager over long-lived tokens stored in build variables. See the Secrets Management and Key Management cheat sheets.
• Pin and verify dependencies. Use lockfiles, integrity hashes and a software bill of materials so a swapped or typosquatted package can't slip into a build. The Dependency Graph SBOM and NPM Security sheets cover this.
• Harden the build runners. Treat build agents as untrusted, minimize installed tooling, and isolate jobs so one pipeline can't read another's artifacts.
• Restrict pipeline permissions. Apply least privilege to CI tokens, require review for changes to workflow files, and separate duties between who writes code and who can deploy.
• Secure the supply chain around the build. Sign artifacts, verify provenance, and scan container images and IaC before deployment (Docker Security, Infrastructure as Code Security).
• Log and monitor. Keep an audit trail of pipeline events and alert on unusual triggers or permission changes (Logging, Logging Vocabulary).

A practical next step

If you are setting this up for a small team, start with two changes: move every deployment credential into a secrets manager with short expiry, and require human review for edits to pipeline configuration files. Those two controls block the most common CI/CD attack paths — stolen tokens and malicious workflow edits — before you invest in artifact signing or SBOM tooling.

Choosing where to focus

The full set lives at OWASP Cheat Sheet Series, where the CI CD Security sheet sits alongside the related sheets above so you can read them as one connected set rather than isolated checklists.