Owasp top 10

What is the OWASP Top 10?


The OWASP Top 10 is a standard "awareness document" published by the Open Worldwide Application Security Project (OWASP). It ranks the 10 most critical security risks facing web applications, based on real-world vulnerability data and industry consensus. It's the baseline reference for developers, pentesters, and auditors — and standards like PCI DSS and ISO 27001 reference it as a best-practice benchmark.


The current edition is **OWASP Top 10:2025** (which replaced the 2021 edition) . Here's the list, what each risk means, and how to test for it.


---


## The 2025 list + how to test each one


### A01 — Broken Access Control

Users can access data or functions beyond their permissions (IDOR, privilege escalation, force browsing). SSRF from the 2021 list is now folded into this category.


**How to test:**

- Create two accounts (user A, user B). Change IDs in URLs/requests (`/api/user/1001` → `1002`) and see if you can read/modify B's data with A's session.

- Force-browse admin paths (`/admin`, `/dashboard`) as a low-privilege user.

- Replay privileged requests after removing/replacing cookies, tokens, or role parameters.

- **Tools:** Burp Suite with the **Autorize** extension (semi-automates access-matrix testing), OWASP ZAP's access control tester.


### A02 — Security Misconfiguration

Default credentials, debug mode in production, directory listing, missing security headers, open cloud storage. (Moved up from #5 in 2021.)


**How to test:**

- Check response headers for missing `Content-Security-Policy`, `Strict-Transport-Security`, `X-Frame-Options`, etc. (securityheaders.com or Burp passive scan).

- Probe for default admin panels, `.git/`, `/.env`, backup files (`config.bak`), directory listing.

- Trigger errors and check whether stack traces leak.

- **Tools:** Nikto, Nmap, Wappalyzer (fingerprinting), ffuf (content discovery).


### A03 — Software Supply Chain Failures

Newly expanded category covering vulnerable/outdated components **and** compromised dependencies, build systems, and third-party code.


**How to test:**

- Fingerprint frameworks/libraries and versions (Wappalyzer, whatweb, `retire.js` for JavaScript libs loaded by the page).

- Compare versions against CVE/NVD databases.

- If you have code access: run **OWASP Dependency-Check**, `npm audit`, `pip-audit`, **Snyk**, or **Trivy** on the dependency manifest.


### A04 — Cryptographic Failures

Sensitive data exposed through weak or missing encryption — the root cause, not the symptom.


**How to test:**

- Scan TLS configuration: weak ciphers, expired certs, TLS 1.0/1.1 still enabled.

- Look for sensitive data sent over HTTP, stored in URLs, localStorage, or cached responses.

- Check for hardcoded keys/secrets in JavaScript files.

- **Tools:** testssl.sh, SSL Labs scan, sslyze.


### A05 — Injection

SQL, NoSQL, OS command, LDAP injection, and XSS — untrusted data interpreted as code.


**How to test:**

- Feed classic payloads into every input point (forms, URL params, headers, cookies): `' OR '1'='1`, `<script>alert(1)</script>`, `; sleep 5`, `{{7*7}}` (SSTI), XML external entities.

- Watch for errors, time delays, or reflected output.

- **Tools:** sqlmap (SQLi), dalfox or XSStrike (XSS), commix (command injection), Burp/ZAP active scanners.


### A06 — Insecure Design

Flaws in the architecture/business logic itself — no scanner will find these.


**How to test:**

- Abuse business flows: reuse a coupon twice, skip a payment step by jumping URLs, exploit race conditions (redeeming a balance with parallel requests — Burp's **Turbo Intruder**), password-reset token predictability.

- Threat-model the app: ask "what could an attacker do with this feature that the designer didn't intend?"


### A07 — Authentication Failures

Weak login, session, and credential-management mechanisms.


**How to test:**

- Check for rate limiting / lockout by hammering the login form (authorized only).

- Test password policy, credential-stuffing resistance, MFA bypass (skip steps, replay).

- Inspect session tokens: are they invalidated after logout? Predictable? JWTs with `alg:none` or weak secrets?

- **Tools:** Burp Intruder, jwt_tool, hydra (only with written permission).


### A08 — Software or Data Integrity Failures

Unverified updates, insecure CI/CD, insecure deserialization.


**How to test:**

- Check whether third-party scripts are loaded with Subresource Integrity (`integrity=` attribute).

- Look for serialized objects in cookies/parameters (Java `rO0...` base64, PHP `O:8:"..."`) and test deserialization payloads.

- Review update mechanisms and CI/CD exposure if in scope.


### A09 — Security Logging & Alerting Failures

Attacks go unnoticed because nothing is logged or alerted on.


**How to test:**

- This is mostly an **audit/review**, not a black-box exploit: deliberately trigger security events (failed logins, access-control violations, scanner traffic) and verify they appear in logs and fire alerts, that logs can't be tampered with, and that retention is adequate.


### A10 — Mishandling of Exceptional Conditions

Brand-new category: systems that fail *open* instead of fail *safe* under abnormal conditions.


**How to test:**

- Fuzz inputs with malformed/oversized/unexpected data (wrong types, huge values, null bytes, negative numbers).

- Observe: does an error grant access instead of denying it? Does a timeout bypass a check? Does an exception leak internals?

- **Tools:** ffuf, Burp Repeater/Intruder, RESTler/Fuzzer for APIs.

Comments

Popular posts from this blog

Types of Hackers

Social Engineering

Hacking Phases