Introduction to the OWASP Top 10 (2021)

Prereqs: Basic web app knowledge (HTTP, HTML/JS), command line familiarity
Goal: Understand the OWASP Top 10 2021 risks from attacker and defender perspectives, and practice the most common exploits safely in OWASP Juice Shop.

Learning Outcomes

By the end, you’ll be able to:

• Explain what OWASP is and why the Top 10 matters.
• Install and run OWASP Juice Shop in a safe lab.
• Describe each 2021 Top 10 category, how attackers exploit it, and how to mitigate it.
• Perform and defend against common Injection and XSS attacks.
• Build practical controls: least privilege, logging & monitoring, CSP, patch management, and secure defaults.

Module 1 — Meet OWASP

What is OWASP?
The Open Web Application Security Project is a nonprofit community improving software security through projects like:

• OWASP Top 10 (this course)
• OWASP Juice Shop (intentionally vulnerable app for practice)
• ModSecurity Core Rule Set (CRS) (WAF rules)
• OWASP API Security Top 10

Why the Top 10?
It’s a consensus view of the most critical web app risks. Use it for threat modeling, secure coding standards, training, and security testing scope.

Module 2 — Lab Setup: OWASP Juice Shop (Docker on Kali/Ubuntu)

Time: 10–15 minutes

Step 1: Install Docker

sudo apt update
sudo apt install -y docker.io
sudo systemctl enable --now docker
Code language: CSS (css)

Step 2: Run Juice Shop

sudo docker pull bkimminich/juice-shop
sudo docker run -d -p 8080:3000 --name juice bkimminich/juice-shop

Step 3: Access the app

• Browse to http://<your-public-ip>:8080 (or http://localhost:8080 if local)
• You’re ready to practice! (Never expose this to the public internet.)

Tip: If docker run fails for permissions, prepend sudo.

Module 3 — 2017 → 2021 Changes (Quick Map)

• Broken Access Control rose to #1.
• Sensitive Data Exposure recategorized as Cryptographic Failures.
• Broken Authentication → Identification & Authentication Failures.
• XXE folded into Security Misconfiguration.
• XSS folded into Injection.
• Insecure Deserialization → Software & Data Integrity Failures.
• Using Components with Known Vulnerabilities → Vulnerable & Outdated Components.
• New on list: Server-Side Request Forgery (SSRF).

Use this when updating legacy checklists and training.

Module 4 — The OWASP Top 10 (2021), Explained

For each risk: Attacker View → What Can Go Wrong → Defenses

1) Broken Access Control

Attacker view: Force-browsing to privileged URLs (/admin), IDOR (changing ?userId=123 to 124), abusing missing server-side checks.

What goes wrong: Users read/modify other users’ data, escalate privileges.

Defenses

• Enforce server-side authorization checks on every request.
• Least privilege roles & permissions; deny by default.
• Use framework authz annotations/policies; test IDOR explicitly.
• Invalidate JWTs on logout; don’t trust client-side claims alone.
• Log & alert on access denials and unusual patterns.

2) Cryptographic Failures

Attacker view: Sniff data in transit, harvest plaintext secrets at rest, exploit weak ciphers/outdated TLS.

Defenses

• TLS everywhere; enable HSTS header.
• Strong algorithms & key sizes; rotate keys.
• Never log secrets; use KMS/secret managers.
• Don’t decrypt→re-encrypt across untrusted hops; keep data encrypted end-to-end where feasible.
• Classify data; encrypt sensitive data at rest and in transit.

3) Injection (SQL/NoSQL/OS/LDAP + XSS included)

Attacker view: Craft input that alters interpreter behavior:

• SQL: ' OR 1=1--
• OS: ; curl http://attacker/…
• LDAP/NoSQL: unescaped filters
• XSS (now under Injection): run arbitrary JS in the victim browser.

Defenses

• Parameterized queries / prepared statements.
• Input validation (allow-list) + output encoding.
• For XSS: CSP (no inline scripts), escape context-specifically (HTML/JS/URL).
• Run app with least OS/database privileges.

4) Insecure Design

Attacker view: Exploit flawed business logic (e.g., coupon misuse, weak workflow checks).

Defenses

• Threat model early (STRIDE, abuse cases).
• Security requirements & secure design patterns (reference architectures).
• Break glass reviews for high-risk flows (auth, payments, exports).

5) Security Misconfiguration

Attacker view: Default creds, verbose errors, open S3 buckets, debug enabled in prod.

Defenses

• Hardened baselines; disable defaults and services you don’t use.
• Infrastructure as Code with peer-reviewed templates.
• Centralized config secrets; environment-specific safe defaults.
• Patch and scan for drift; secure HTTP headers.

6) Vulnerable & Outdated Components

Attacker view: Race to exploit NVD/CVE disclosures and Shodan-exposed targets.

Defenses

• SBOM + dependency inventory.
• Automated dependency updates (Dependabot/Renovate).
• Risk-based patch SLAs; block builds on critical CVEs.

7) Identification & Authentication Failures

Attacker view: Credential stuffing, weak passwords, long-lived sessions.

Defenses

• MFA for all sensitive actions.
• Strong password policy + breach checks.
• Session timeouts, SameSite/HttpOnly/Secure cookies; don’t expose session IDs in URLs.
• Rate limiting login; lockout/cooldowns.

8) Software & Data Integrity Failures

Attacker view: Supply chain exploits (malicious updates, tampered packages).

Defenses

• Signed artifacts (Sigstore/Cosign); verify on deploy.
• Pin dependencies; restrict build permissions.
• Immutable, reproducible builds.

9) Security Logging & Monitoring Failures

Attacker view: Operate without detection; persistence and lateral movement.

Defenses

• Log auth, privileged actions, data access, and errors with timestamps and request IDs.
• Centralize to a SIEM; alert on brute-force, access denials, anomaly spikes.
• Incident response runbooks and regular drills.

10) Server-Side Request Forgery (SSRF)

Attacker view: Coerce server to fetch internal URLs (IMDS, admin consoles).

Defenses

• Deny egress to internal networks; URL allow-lists.
• Validate/normalize URLs server-side; disable redirects.
• Use IMDSv2 / metadata service hardening in cloud.

Module 5 — Hands-On Labs (Juice Shop)

Always attack only your lab environment.

Lab A: SQL Injection (Login Bypass)

1. Open Juice Shop → Login.
2. In Email: '+OR 1=1--
   Password: anything.
3. Observe admin login (or enumerated user).

Why it works: The injected predicate forces the WHERE clause true; -- comments out the remainder.

Fix it (conceptually):

• Use parameterized queries.
• Sanitize input and enforce types/length.
• Minimize DB privileges (no writes for read-only flows).

Lab B: XSS (Reflected/DOM)

1. Use the search field.
2. Try a harmless payload that proves script execution (e.g., DOM-based XSS using an injected element).

Defenses to discuss:

• Encode output per context.
• CSP with no inline scripts; script-nonce.
• Validate and reject unexpected characters for specific fields.

Module 6 — Secure Defaults in Cloud (Mini Demo Plan)

Example: S3 bucket hardening checklist

• Block public access (account & bucket level).
• Default encryption (SSE-S3 or SSE-KMS).
• Least-privilege bucket policies and IAM roles.
• Versioning & access logging enabled.

(Adapt similar hardening for web servers, DBs, object stores.)

Module 7 — Quick Checks (Assessments)

5 questions

1. Which control best prevents IDOR?
   a) CSP b) Server-side authorization per object c) Captcha
   Ans: b
2. Storing SSNs in plaintext violates which category most directly?
   Ans: Cryptographic Failures
3. The most reliable fix for SQL injection is:
   Ans: Parameterized queries
4. Which header helps reduce XSS impact?
   Ans: Content-Security-Policy (CSP)
5. Which is a hallmark of SSRF?
   Ans: Server makes requests to internal resources on attacker’s behalf

Module 8 — Operationalizing the Top 10

Team Playbook

• Build time: lint/scan deps; block high CVEs; unit tests for authz and validation.
• Pre-prod: DAST on key flows; threat model delta changes.
• Prod: SIEM alerts, WAF with CRS, rate limits, auth anomalies.
• Governance: Update secure coding standards to 2021 categories; training + labs quarterly.

Headers Starter Pack (examples)

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(), camera=()
Code language: HTTP (http)

Cheatsheets & Job Aids

Injection Defense (DB)

• Prepared statements only
• ORM escaping rules respected
• Input allow-lists, length limits
• Read-only DB roles for read paths

Auth & Session

• MFA + breached password checks
• Short session TTL; refresh tokens rotated
• Cookies: Secure; HttpOnly; SameSite=Strict

Access Control

• Enforce server-side, per-object checks
• Deny-by-default routes
• Role reviews every release

Logging & IR

• Centralize logs with request IDs
• Alert on 401/403 spikes, failed logins, admin actions
• Incident runbooks and on-call

Conclusion & Next Steps

• Keep practicing in OWASP Juice Shop—repeat the labs and try new challenges.
• Fold these controls into your pipelines: dependency updates, IaC hardening, authz tests, and headers.
• Stay engaged with your local OWASP chapter and the broader community.

Stretch Goals

• Add WAF (ModSecurity CRS) in front of Juice Shop and observe blocked payloads.
• Implement CSP nonces and measure what breaks—then fix it the right way.
• Generate an SBOM and track CVEs over time.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.