Skip to content

OWASP Basics

OWASP is a practical, community-driven source of web application security guidance. The OWASP Top 10 is not a checklist to memorize for its own sake; it is a map of the most common and damaging categories of web app risk.

This cheat sheet is defensive and educational. It explains concepts and safe practices, not how to exploit them.

What OWASP Is

  • OWASP stands for the Open Web Application Security Project.
  • It publishes freely available guidance, including the Top 10, testing guides, and cheat sheets.
  • The Top 10 is a widely used summary of common web application security risks.

The exact list evolves over time, so treat it as a starting point for learning the categories, not as a frozen law.

The Big Patterns Behind the Top 10

Most web application security problems share a few root causes:

  • Trusting input too much — user data, headers, files, APIs, and even internal services can send bad data.
  • Doing authorization in the browser or UI only — the server must enforce access.
  • Reusing weak or default credentials and configurations — convenience often becomes risk.
  • Mixing data and code — SQL, shell, templates, and other interpreters can confuse data with commands.
  • Exposing too much — error messages, debug endpoints, internal APIs, and metadata can help an attacker.
  • Failing to see the application as an attack surface — every endpoint, upload, form, and integration is a place to defend.

Common Risk Categories

These are general descriptions, not a verbatim copy of any specific version of the Top 10.

Broken Access Control

The application does not correctly enforce what a user may do.

Typical signs: - One user can see another user's data by changing an ID. - UI-only restrictions with no server-side check. - APIs that assume the caller is authorized without verifying.

Defenses: - Check authorization on every request on the server. - Use coarse-grained roles and fine-grained checks where needed. - Avoid exposing internal object references without protection. - Test with multiple user roles.

Cryptographic Failures

Sensitive data is not protected adequately in transit or at rest, or crypto is used incorrectly.

Typical signs: - Sending sensitive data over unencrypted channels. - Using weak algorithms, short keys, or deprecated modes. - Storing passwords or tokens in ways that are easy to recover. - Poor key management.

Defenses: - Use TLS for sensitive traffic. - Encrypt sensitive data at rest where appropriate. - Use well-supported libraries rather than inventing your own crypto. - Manage keys and secrets carefully. - Hash passwords properly.

Injection

Untrusted data is interpreted as code or commands by a parser, database, shell, template engine, or similar.

Common forms: - SQL injection - Command injection - Template injection - NoSQL injection - LDAP or other query injection

Defenses: - Use parameterized queries or safe APIs. - Keep data and commands separate. - Validate and sanitize input at the boundary. - Avoid building queries by string concatenation when a safer option exists. - Limit what the application can do from a technical standpoint.

Insecure Design

The application is built in a way that makes a vulnerability likely, even before implementation details are considered.

Typical signs: - No threat modeling for sensitive flows. - Trusting external systems too much by default. - Missing limits on expensive operations. - Weak separation between roles and data.

Defenses: - Think about risks early. - Model trust boundaries. - Define what "secure" means for the feature before coding. - Review designs that touch auth, money, data access, or abuse-prone actions.

Security Misconfiguration

The application or its environment is deployed with unsafe defaults or unnecessary exposure.

Typical signs: - Debug modes left on. - Default credentials still active. - Unnecessary features, pages, or services exposed. - Bad error handling that leaks internal details. - Cloud or container misconfigurations.

Defenses: - Harden defaults. - Disable what you do not need. - Review configuration as part of deployment. - Use repeatable, version-controlled configuration where possible. - Test in an environment that mirrors production.

Vulnerable and Outdated Components

Libraries, frameworks, and services with known weaknesses are used.

Typical signs: - Old versions with known issues. - Unmanaged dependencies. - No process for tracking and updating components. - Blind trust in transitive dependencies.

Defenses: - Track what your application depends on. - Update when fixes are available. - Remove unused dependencies. - Use automated scanning where practical. - Understand that a component you do not write still affects your risk.

Identification and Authentication Failures

Login, session handling, and identity verification are weak or inconsistent.

Typical signs: - Weak password policies. - Predictable or poorly protected session tokens. - No multi-factor option where it matters. - Credential stuffing or brute-force exposure. - Session handling that does not expire or invalidate properly.

Defenses: - Use strong, well-tested authentication mechanisms. - Protect sessions and tokens. - Add MFA for sensitive access. - Rate-limit or otherwise slow abuse. - Log authentication events.

Software and Data Integrity Failures

The application trusts code, updates, configurations, or data without adequate verification.

Typical signs: - Loading plugins, models, or data without integrity checks. - Trusting deserialized data too readily. - Accepting unsigned updates or payloads. - Relying on a pipeline that could be tampered with.

Defenses: - Verify signatures or hashes where appropriate. - Treat model files, datasets, and plugins as untrusted until verified. - Use secure build and deployment practices. - Limit deserialization and dynamic loading to what is necessary.

Security Logging and Monitoring Failures

The application does not record enough, or does not act on, the signals that would help detect and respond to attacks.

Typical signs: - No logging of auth failures or access-control violations. - Logs missing context. - No alerting. - Logs that omit important events because they were never defined.

Defenses: - Log security-relevant events. - Include enough context to investigate. - Review logs and alerts. - Make sure logs do not expose sensitive data unnecessarily.

Server-Side Request Forgery

The server is tricked into making requests to internal or external resources on behalf of an attacker.

Typical signs: - The application fetches a user-supplied URL. - Internal services are reachable from the application and not properly protected. - Redirects or webhooks are followed without restriction.

Defenses: - Validate and restrict what the application may fetch. - Limit outbound access where possible. - Do not treat user-supplied URLs as safe. - Segment internal services so one compromised app is not a universal proxy.

Server-Side Template Injection and Similar

User data is merged into templates or interpreted contexts in unsafe ways.

Defenses: - Use the template engine's safe escaping features. - Avoid passing user input into template logic when possible. - Keep data and code paths separate. - Review how templates are rendered.

Why OWASP Matters for AI and Data Apps

Data-driven applications have the same web risks as other applications, plus a few that show up often:

  • Model endpoints can become abuse targets.
  • File uploads and dataset ingestion expand the attack surface.
  • API keys and service credentials often appear in AI workflows.
  • Third-party model and data services introduce new trust boundaries.
  • Output from models can be treated as "just text," but it still flows through your application and may need validation or moderation.

Web security is not only about login pages and shopping carts. It is about any service that accepts input, makes decisions, or touches data.

A Practical Defensive Workflow

  1. Identify trust boundaries. Where does your application receive input, call other services, or expose data?

  2. Decide what each boundary must guarantee. Confidentiality, integrity, access, and availability for that boundary.

  3. Choose controls for each boundary. Validation, parameterization, authorization, TLS, limiting, logging, rate limiting, and so on.

  4. Check the defaults. Debug mode, credentials, exposed services, verbose errors.

  5. Test the risky paths. Authentication, authorization, upload, payment, admin features, and anything that touches sensitive data.

  6. Log and review. If a control fails, you want to know.

Testing Mindset

You do not need to be an attacker to test securely.

  • Try to access another user's data with a different session or ID.
  • Try to perform an action your role should not allow.
  • Supply unexpected input types, lengths, and formats.
  • Try to upload odd file names, content, or metadata.
  • Try to make the server fetch or redirect to odd targets.
  • Check what errors and debug information leak.
  • Verify that dependencies are up to date.

The point is to break your own assumptions before someone else does.

Common Mistakes

  • Relying on the UI for access control
  • Building SQL, shell, or template content by concatenation
  • Leaving debug endpoints and verbose errors enabled in production
  • Using default passwords on anything important
  • Ignoring dependencies because they are "just libraries"
  • Treating internal services as automatically trusted
  • Allowing the application to fetch arbitrary URLs
  • Not logging authentication and authorization failures
  • Forgetting that model files, datasets, and plugins can be attack vectors too

Official and Community Resources

  • OWASP Top 10 — the canonical summary of common web app risks
  • OWASP Cheat Sheet Series — topic-specific defensive guidance
  • OWASP Testing Guide — structured approaches to reviewing application security

Use these as reference material and learning sources. Adapt them to the services you actually build and operate.

Last Updated

2026-09-06 — Initial version.