The OWASP Top 10:2025 is the industry-standard awareness document listing the ten most critical web application security risks: broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions. Automated scanners cover roughly 4 of the 10 categories. Broken access control, business logic flaws, and SSRF (now folded into broken access control) require manual testing by a skilled pentester. Indian compliance frameworks (ISO 27001, SOC 2, RBI guidelines, SEBI CSCRF) all expect OWASP Top 10 coverage in pentest reports.
You’ve seen “OWASP Top 10” show up in a pentest report, a client security questionnaire, or a compliance checklist. Maybe all three. It gets referenced constantly, but most dev teams have never actually walked through all ten categories and asked: does this apply to us?
This post does exactly that. We’ll cover each of the ten categories in the OWASP Top 10:2025 with a practical example from the kind of SaaS apps we test every month, whether your scanner will catch it, and what it actually takes to fix it.
If you’re building a SaaS product in India and selling to customers who care about security (enterprise buyers, regulated industries, international markets), this is the list your app gets tested against.
Why OWASP Top 10 Matters for Indian SaaS
The OWASP Top 10 is not a compliance standard. It’s an awareness document. But it has become the de facto checklist that pentest firms, auditors, and enterprise buyers use to evaluate web application security.
When a customer asks for a “pentest report covering OWASP Top 10,” they’re asking whether your app has been tested for these ten categories of vulnerabilities. When an ISO 27001 auditor reviews your security testing evidence, they expect to see OWASP Top 10 referenced in the methodology. The OWASP Web Security Testing Guide (WSTG) provides the detailed test cases behind each category.
For Indian SaaS companies selling to US or European enterprise customers, OWASP Top 10 coverage in your pentest report is table stakes. It’s not optional.
The 10 Categories: What Each Means for Your SaaS App
A01:2025 Broken Access Control
What it is: Users can act outside their intended permissions. This held the #1 spot in both the 2021 and 2025 editions. It covers everything from IDOR (insecure direct object references) to missing function-level access checks. In the 2025 edition, server-side request forgery (SSRF), which was its own category in 2021, is now folded in here, since SSRF is fundamentally a failure of access control over which destinations the server may reach.
What it looks like in your app: Your multi-tenant SaaS lets User A from Company X access Company Y’s data by changing an ID in the URL or API call. Or a regular user discovers they can hit /admin/users and it returns the full user list because authorization is only enforced in the frontend, not the API. On the SSRF side: your app has a “preview URL” feature that renders a screenshot of any URL, and an attacker supplies http://169.254.169.254/latest/meta-data/iam/security-credentials/ to pull your cloud IAM credentials.
Scanner or manual? Manual. Scanners cannot understand your authorization model. They don’t know that User A shouldn’t see User B’s data. A pentester creates multiple test accounts with different roles and tenants, then systematically tests every endpoint for horizontal and vertical privilege escalation. Blind SSRF (where the response isn’t returned to the user) and SSRF via redirects also require manual exploration.
Fix it: Enforce authorization checks server-side on every request. Don’t rely on hiding UI elements. Use indirect references (UUIDs mapped to internal IDs per session) where possible. Deny by default. For SSRF, validate all user-supplied URLs, block requests to internal IP ranges, and use IMDSv2 on AWS to require session tokens for metadata access.
A02:2025 Security Misconfiguration
What it is: Default credentials, unnecessary features enabled, overly permissive cloud configurations, missing security headers, verbose error messages that leak stack traces. This category moved up from #5 in 2021 to #2 in 2025, reflecting how often exposed defaults drive real incidents.
What it looks like in your app: Your staging environment is publicly accessible with default admin credentials. Your S3 bucket policy allows s3:GetObject for *. Django debug mode is on in production, showing full stack traces with file paths and environment variables. Your API returns detailed error messages like "error": "column 'password_hash' not found in table 'users'".
Scanner or manual? Mostly scannable. Tools like ScoutSuite (cloud), Nuclei (web), and security header checkers can flag most misconfigurations. But context matters: a pentester evaluates whether a specific configuration is actually exploitable in your environment, not just theoretically risky.
Fix it: Automate configuration checks in CI/CD. Strip debug output in production. Review cloud IAM policies quarterly. Use security headers (CSP, HSTS, X-Frame-Options). Remove default accounts and sample applications from production deployments.
A03:2025 Software Supply Chain Failures
What it is: New in 2025. This category broadens the 2021 “Vulnerable and Outdated Components” entry to the whole dependency and build chain: known-CVE libraries, but also compromised packages, poisoned CI/CD pipelines, unsigned artifacts, and untrusted third-party code across your build and distribution systems. It includes direct dependencies and transitive ones (dependencies of dependencies).
What it looks like in your app: Your package.json pins an old version of lodash with a prototype pollution vulnerability. Your Java app uses Log4j 2.14 (the Log4Shell version). Your Docker base image hasn’t been updated in 18 months and has 47 known CVEs. A compromised npm package in your dependency tree injects a cryptominer during install. Your CI/CD pipeline pulls dependencies without verifying checksums.
Scanner or manual? Mostly scannable for the components part. SCA tools (Snyk, Dependabot, Trivy) compare your dependency tree against CVE databases. Manual effort is needed to evaluate whether a CVE is actually exploitable in your specific usage context, and to review CI/CD pipeline permissions and build-system integrity, which no scanner fully covers.
Fix it: Run SCA tools in CI. Set up Dependabot or Renovate for automated dependency PRs. Maintain a software bill of materials (SBOM). Verify checksums and signatures for all dependencies. Use lockfiles. Review CI/CD pipeline permissions with least privilege. Have a process for evaluating and patching critical CVEs within 48 hours.
A04:2025 Cryptographic Failures
What it is: Formerly called “Sensitive Data Exposure,” this was #2 in 2021 and dropped to #4 in 2025. It covers weak or missing encryption for data in transit and at rest, hardcoded secrets, weak hashing algorithms, and improper certificate validation.
What it looks like in your app: Your app stores passwords with MD5 or SHA-1 instead of bcrypt/argon2. API keys are committed to your Git repo. Internal services communicate over plain HTTP. User PII sits unencrypted in your database, and your backup bucket is publicly accessible over HTTP.
Scanner or manual? Both. Scanners can detect missing TLS, weak cipher suites, and exposed secrets in responses. But finding hardcoded credentials in source code, weak key derivation, or improper certificate pinning in mobile apps requires manual review.
Fix it: Use TLS 1.2+ everywhere, including internal services. Hash passwords with bcrypt or argon2. Encrypt PII at rest. Rotate secrets regularly and never commit them to version control. Run trufflehog or gitleaks in your CI pipeline.
A05:2025 Injection
What it is: SQL injection, NoSQL injection, OS command injection, LDAP injection, and cross-site scripting (XSS). Untrusted data is sent to an interpreter as part of a command or query without proper validation or escaping. This was #3 in 2021 and moved to #5 in 2025.
What it looks like in your app: Your search feature builds SQL queries by concatenating user input: SELECT * FROM products WHERE name LIKE '%${userInput}%'. An attacker inputs '; DROP TABLE products; -- and your database is gone. Or your app shells out to a system command using user-supplied filenames without sanitization.
Scanner or manual? Both. Automated scanners (Burp, OWASP ZAP) are good at finding classic SQL injection with error-based or time-based detection. But second-order injection (where the payload is stored and executed later in a different context) and NoSQL injection against MongoDB queries require manual testing.
Fix it: Use parameterized queries or prepared statements. Always. For every database interaction. Use ORMs correctly (they protect you only if you don’t bypass them with raw queries). Validate and sanitize all input on the server side.
A06:2025 Insecure Design
What it is: First introduced in 2021, this addresses flaws in the design itself, not the implementation. A perfectly coded feature can still be insecure if the design didn’t account for abuse scenarios. It sat at #4 in 2021 and moved to #6 in 2025.
What it looks like in your app: Your referral system gives credits for every new signup, but doesn’t prevent a user from creating fake accounts to farm credits. Your password reset flow sends a 4-digit OTP with no rate limiting, making brute-force trivial (10,000 combinations, even at 1 request/second that’s under 3 hours). Your file-sharing feature lets users generate public links with no expiration.
Scanner or manual? Manual only. No scanner can evaluate business logic. This is the category where experienced pentesters earn their keep, thinking through abuse scenarios, edge cases, and race conditions that the development team didn’t consider.
Fix it: Threat model during design, not after deployment. Use abuse case stories alongside user stories. Ask “how would someone exploit this?” for every feature that involves money, access, or data sharing.
A07:2025 Authentication Failures
What it is: Renamed in 2025 from “Identification and Authentication Failures” (and “Broken Authentication” before that). Covers weak password policies, credential stuffing, session fixation, missing MFA, and improper session management.
What it looks like in your app: Your app accepts passwords like “12345678” because the policy only checks length, not complexity. Login attempts aren’t rate-limited, so attackers can try thousands of passwords per minute. Sessions don’t expire after logout (the JWT is still valid server-side). Your “remember me” token is a predictable value.
Scanner or manual? Both. Scanners can check password policies and session cookie flags. But testing for account enumeration (does the login page say “invalid email” vs “invalid password”?), session fixation, token predictability, and MFA bypass requires manual testing.
Fix it: Enforce strong password policies (length > complexity). Implement rate limiting and account lockout. Use secure session tokens with proper expiration. Add MFA, especially for admin accounts. Don’t reveal whether an email exists during login or registration.
A08:2025 Software or Data Integrity Failures
What it is: First introduced in 2021 and held at #8 in 2025. This covers code and infrastructure that doesn’t protect against integrity violations: insecure CI/CD pipelines, unsigned updates, deserialization of untrusted data.
What it looks like in your app: Your CI/CD pipeline pulls dependencies without verifying checksums. A compromised npm package in your supply chain injects a cryptominer. Your app deserializes user-supplied JSON/YAML without validation, allowing object injection. Auto-update mechanisms download updates over HTTP without signature verification.
Scanner or manual? Mostly manual. Scanners can detect some deserialization issues, but supply chain risks, CI/CD pipeline weaknesses, and integrity verification gaps require architectural review. This is increasingly important, the SolarWinds and Codecov breaches were both integrity failures.
Fix it: Verify checksums and signatures for all dependencies. Use lockfiles (package-lock.json, Gemfile.lock). Sign your releases. Review CI/CD pipeline permissions (principle of least privilege). Validate all deserialized data against a strict schema.
A09:2025 Security Logging and Alerting Failures
What it is: Renamed in 2025 from “Security Logging and Monitoring Failures” to emphasise alerting. Insufficient logging of security-relevant events, or logging that exists but nobody is alerted on. Without detection, attackers operate unnoticed for weeks or months.
What it looks like in your app: Failed login attempts aren’t logged. Your application logs don’t capture who accessed what data. You have CloudWatch running but no alerts configured for anomalous patterns. When a customer asks “was my data accessed?”, you can’t answer because there’s no audit trail.
Scanner or manual? Manual. No scanner can verify your logging coverage or monitoring effectiveness. A pentester checks whether their test activities (failed logins, access control bypass attempts, injection payloads) show up in your logs. If they don’t, that’s a finding.
Fix it: Log all authentication events (success and failure), access control failures, input validation failures, and admin actions. Include enough context (who, what, when, from where) to reconstruct an incident. Set up alerts for anomalous patterns. Retain logs for at least 90 days (longer if compliance requires it).
A10:2025 Mishandling of Exceptional Conditions
What it is: New in 2025. This category brings together error handling, fail-open logic, and resilience problems that were previously scattered across quality-related weaknesses. It covers what happens when your application hits an unexpected state: does it fail closed and safe, or fail open and leak?
What it looks like in your app: Your payment webhook handler catches an exception and defaults to “mark order paid” instead of rejecting. An unhandled error in your authorization middleware falls through to granting access rather than denying it. A verbose exception leaks a stack trace with database schema and internal file paths to the end user. A retry loop on a failed downstream call silently double-charges a customer.
Scanner or manual? Mostly manual. Scanners can flag some verbose error responses, but reasoning about whether a failure path leaves your app in an insecure state, whether a caught exception fails open, or whether an edge-case input triggers unsafe behaviour requires a tester who understands your control flow.
Fix it: Fail closed by default on every security-relevant decision. Handle exceptions explicitly rather than swallowing them. Never leak stack traces or internal detail to end users. Make sure retry, timeout, and fallback logic cannot bypass a control or duplicate a state change.
When we scope a pentest we test against these controls and the current OWASP Web Security Testing Guide (WSTG v4.2), so the report maps cleanly whether your auditor references the 2021 or the 2025 list.
How OWASP Top 10 Maps to Pentest Scope
When you commission a penetration test, the OWASP Top 10 gives structure to the engagement. Here’s how the categories map to what a pentester actually does:
| OWASP Category | Pentest Activity | Effort |
|---|---|---|
| A01:2025 Broken Access Control | Multi-role, multi-tenant testing across all endpoints, plus SSRF probing | High (manual) |
| A02:2025 Security Misconfiguration | Configuration audit, header checks, cloud review | Low-Medium (automated) |
| A03:2025 Software Supply Chain Failures | Dependency scanning, version fingerprinting, CI/CD and build-system review | Low-Medium (automated + manual) |
| A04:2025 Cryptographic Failures | TLS analysis, password storage review, secrets scanning | Medium |
| A05:2025 Injection | Fuzzing all input points, testing query construction | Medium (automated + manual) |
| A06:2025 Insecure Design | Business logic abuse testing, threat modeling review | High (manual) |
| A07:2025 Authentication Failures | Auth flow testing, session management, MFA bypass | Medium (manual) |
| A08:2025 Software or Data Integrity Failures | CI/CD review, deserialization testing, integrity checks | Medium (manual) |
| A09:2025 Security Logging and Alerting Failures | Verify detection and alerting on test activities in logs | Low (manual) |
| A10:2025 Mishandling of Exceptional Conditions | Error-path and fail-open testing, edge-case abuse | Medium (manual) |
Notice the pattern: the categories that cause the most damage (A01, A06, A07) are the ones that need manual testing. Automated scanners handle the low-hanging fruit (A02, A03), but the vulnerabilities that lead to data breaches require a human tester who understands your application’s context.
This is why a “vulnerability scan” is not the same as a “penetration test.” A scan covers maybe 3-4 of these categories well. A proper pentest covers all 10. For more on this distinction, read our breakdown of what VAPT actually involves.
OWASP Top 10 and the API Layer
If your SaaS is API-first (and most modern SaaS products are), the OWASP Top 10 for web applications is only half the picture. OWASP also publishes a separate API Security Top 10 that targets API-specific risks like broken object-level authorization (BOLA), mass assignment, and unrestricted resource consumption.
A thorough pentest covers both. We’ve written a detailed walkthrough of the OWASP API Top 10 and what it means for your product.
What to Do With This
If you’re building a SaaS product and haven’t had a pentest that explicitly covers OWASP Top 10, here’s the move:
-
Run the free stuff first. Set up Dependabot for A03 (software supply chain). Add security headers for A02 (misconfiguration). Switch to parameterized queries for A05 (injection). These are engineering hygiene items you can fix this week.
-
Get a pentest for the manual stuff. A01 (access control, which now includes SSRF), A06 (insecure design and business logic), A07 (auth), and A10 (mishandling of exceptional conditions) need a human tester who will create test accounts, map your authorization model, and try to break it. No scanner does this. Our web application penetration testing covers all 10 OWASP categories with manual testing led by our OSCP-certified co-founder.
-
Use the report for compliance. A pentest report that references OWASP Top 10 methodology satisfies requirements for ISO 27001, SOC 2, and most enterprise security questionnaires.
Our Startup Pentest plan (INR 74,999) covers OWASP Top 10 testing for a single scope (web app or API) with 7-day delivery. The Growth Pentest plan (INR 1,79,999) covers 2 scopes and includes SOC 2 + ISO 27001 audit prep. Both include a detailed report mapping findings to OWASP categories.
Want to see what the output looks like? Request a sample report. You can also see our full penetration testing services for scope and methodology details, or book a 30-min discovery call with the founders to walk OWASP coverage against your specific scope.