OWASP ASVS 5.0 Explorer

Most injection attacks, including cross site scripting and SQL injection, happen when untrusted data is treated as code. This chapter makes sure data stays data.

• Encode output for the right context, so user input is shown as text and never runs as code.
• Use parameterized queries so input cannot change the meaning of a database query.
• Sanitize or reject unsafe input, and handle deserialization of untrusted data with care.

• Do you encode all user input before showing it in a page?
• Do you use parameterized queries for every database call?

• Cross Site Scripting (XSS): Impact and OWASP Prevention ›
• SQL Injection: How It Works and How to Prevent It ›
• Content Security Policy: A Practical Guide ›

Attackers break workflows by sending unexpected values or by repeating actions at machine speed. Validation and anti automation controls keep your logic safe.

• Validate input against a strict schema of what you expect, on the server.
• Enforce business rules in order, so steps cannot be skipped or replayed.
• Add anti automation limits so bots cannot abuse sensitive actions.

• Do you validate every input on the server, not only in the browser?
• Do you limit how often sensitive actions can run?

• SQL Injection: How It Works and How to Prevent It ›
• What Is Prompt Injection? ›

The browser runs your code next to untrusted content. Cookie flags, security headers, and origin rules decide how much damage a frontend flaw can cause.

• Set a Content Security Policy to limit which scripts can run.
• Set HttpOnly, Secure, and SameSite on session cookies.
• Send browser security headers and keep origins separated.

• Do you send a Content Security Policy header?
• Are your session cookies HttpOnly, Secure, and SameSite?

• Content Security Policy: A Practical Guide ›
• Session Management and Secure Cookies ›
• CSRF: Attacks and Defenses ›

APIs are a direct path to your data. They need authentication, input checks, and limits just like any page, plus protection for their specific protocols.

• Authenticate and authorize every API call, and never trust the client.
• Validate the structure of each request and reject malformed messages.
• Apply rate limits and add specific rules for GraphQL and WebSocket.

• Does every API endpoint check authentication and authorization?
• Do you rate limit your API?

• JWT vs Session Tokens: Which Is More Secure? ›
• Rate Limiting and Account Lockout ›

Uploaded files can carry malware, overwrite data, or run as code. Safe handling of upload, storage, and download closes these paths.

• Check file type and size, and store uploads outside the web root.
• Give stored files safe names and never run them as code.
• Control downloads so users cannot reach files they should not.

• Do you validate the type and size of every uploaded file?
• Are uploaded files stored where they cannot be executed?

• Secure File Uploads: How to Handle User Files Safely ›

Authentication is the front door of your app. Weak passwords, missing multifactor, and unsafe recovery let attackers in with stolen or guessed credentials.

• Block breached and weak passwords, and do not limit password length or characters unfairly.
• Offer multifactor authentication and protect the account recovery flow.
• Rate limit and lock out repeated failed logins to stop brute force and credential stuffing.

• Do you block breached passwords at signup?
• Do you offer multifactor authentication?
• Do you rate limit failed logins per account and globally?

• OwlAuth: authentication library for Node.js ›
• Brute Force Attacks: How to Prevent Them ›
• Credential Stuffing: How to Stop It ›
• Password Spraying: How to Prevent It ›
• Breached Password Detection with HaveIBeenPwned ›

A session id is a temporary key to an account. If it is weak, never expires, or is not destroyed on logout, attackers can take over sessions.

• Generate long random session ids and regenerate them on login.
• Set idle and absolute timeouts, and end the session on the server at logout.
• Defend against session abuse such as fixation and reuse.

• Do you regenerate the session id after login?
• Do you destroy sessions on the server at logout?

• Session Management and Secure Cookies ›
• JWT vs Session Tokens: Which Is More Secure? ›

Authentication proves who you are. Authorization decides what you may do. Missing checks lead to broken access control, the top risk in the OWASP Top 10.

• Check permissions on the server for every action, not only in the interface.
• Follow least privilege, so each user and service gets the minimum access it needs.
• Enforce authorization at the operation and data level, not just the page.

• Do you check authorization on the server for every sensitive action?
• Do you apply least privilege to users and services?

• Excessive Agency: least privilege for AI agents ›

Self contained tokens carry their own trust. If they are signed weakly, never checked, or hold secrets, attackers can forge access or read sensitive data.

• Verify the signature and reject the none algorithm and any unexpected algorithm.
• Check issuer, audience, expiry, and purpose on every token.
• Never store secrets in a token payload, since it is only encoded, not encrypted.

• Do you verify the token signature and allowed algorithms on every request?
• Do you check expiry, issuer, and audience?

• OwlTokenGuard: token management for Node.js ›
• JWT vs Session Tokens: Which Is More Secure? ›

OAuth and OpenID Connect power social login and third party access. Small mistakes in flows, redirects, or token handling can expose whole accounts.

• Use the authorization code flow with PKCE and validate redirect uris strictly.
• Validate tokens and the state parameter to stop forgery and mix up attacks.
• Manage consent and scopes carefully on both client and server.

• Do you use the authorization code flow with PKCE?
• Do you strictly validate redirect uris and the state parameter?

• OAuth 2.0 and OpenID Connect Security Made Simple ›
• JWT vs Session Tokens: Which Is More Secure? ›

Weak or misused cryptography exposes passwords and data. This chapter covers safe algorithms, correct password hashing, and secure random values.

• Hash passwords with bcrypt, scrypt, or Argon2, never with plain SHA or MD5.
• Use strong, current encryption algorithms and manage keys safely.
• Generate random values with a cryptographically secure source.

• Do you hash passwords with bcrypt, scrypt, or Argon2?
• Do you use a secure random source for tokens and keys?

• Breached Password Detection with HaveIBeenPwned ›
• Passwordless Authentication with Magic Links ›

Without strong TLS, attackers can read or change traffic. This chapter covers HTTPS for public services and encryption for internal service calls.

• Serve all traffic over HTTPS and enable HSTS.
• Use current TLS versions and strong settings, and disable old ones.
• Encrypt service to service traffic inside your network too.

• Is every page and API served over HTTPS?
• Have you disabled old TLS versions?

• HTTPS and TLS Security: A Plain Guide ›
• Session Management and Secure Cookies ›

Insecure defaults, leaked secrets, and noisy errors give attackers easy wins. Good configuration removes them before release.

• Store secrets in a secret manager, never in code or version control.
• Remove default accounts, debug modes, and verbose errors in production.
• Keep dependencies current and configure backend communication safely.

• Are all secrets kept out of your code and git history?
• Is debug mode off and are errors generic in production?

• Secure Configuration and Secrets Management ›

Sensitive data needs care wherever it lives. This chapter limits caching, controls client storage, and reduces how much data you keep.

• Classify sensitive data and limit how long you keep it.
• Control client side storage and caching of sensitive values.
• Apply protection based on how sensitive each field is.

• Do you know which data is sensitive and where it is stored?
• Do you limit caching and client storage of sensitive data?

• Data Protection in Web Apps: A Simple Guide ›

Many flaws come from design choices and unsafe code patterns. Threat modeling, safe dependencies, and defensive coding prevent them early.

• Threat model your design to find risks before you build.
• Track dependencies and remove unsafe or unused ones.
• Write defensive code and handle concurrency safely.

• Do you threat model new features before building them?
• Do you track and update your dependencies?

• What Is Threat Modeling? A Practical Guide ›
• STRIDE vs DREAD vs PASTA ›
• The OWASP Top 10 for LLM Applications ›

Without good logs you cannot detect or investigate attacks. Poor error handling can leak secrets. This chapter balances both.

• Log security events such as logins, failures, and access changes.
• Protect logs from tampering and never log secrets or sensitive data.
• Return generic errors to users and keep the detail in server logs.

• Do you log failed logins and important security events?
• Do your error messages avoid leaking stack traces or secrets?

• OwlAuth: built in security audit logging ›

WebRTC powers calls and live data in the browser. Its TURN servers, media, and signaling each need protection against abuse and interception.

• Secure and authenticate TURN servers to stop relay abuse.
• Encrypt media and protect the signaling channel.
• Validate signaling messages to prevent hijacking.

• Are your TURN servers authenticated and rate limited?
• Is your signaling channel encrypted and validated?

• WebRTC Security: How to Keep Calls and Data Safe ›