owasp-security

# Comprehensive OWASP Security Skills A developer-focused security reference covering six OWASP standards for securing web applications, APIs, mobile apps, containers, and AI/LLM systems. Each section provides concise detection guidance, key requirements, and mitigation strategies. ## Quick Navigation 1. [OWASP Top 10 (2021)](#section-1-owasp-top-10-2021) 2. [OWASP ASVS 5.0](#section-2-owasp-asvs-50-application-security-verification-standard) 3. [OWASP MASVS v2.1.0](#section-3-owasp-masvs-v210-mobile-security) 4. [OWASP API Security Top 10](#section-4-owasp-api-security-top-10-2023) 5. [OWASP Kubernetes Top 10](#section-5-owasp-kubernetes-top-10-2022) 6. [OWASP Agentic Applications 2026](#section-6-owasp-agentic-applications-2026) --- ## Section 1: OWASP Top 10 (2021) The OWASP Top 10 represents the most critical security risks in web applications. ### A01: Broken Access Control **Detection:** URLs with direct ID references (`/user/1234/orders`); client-side only enforcement; missing authorization checks. **Mitigation:** Enforce server-side authorization for every sensitive operation; verify user ownership of resources; implement default-deny principle. **Example:** ```javascript // INSECURE: No authorization check app.get('/users/:id/orders', (req, res) => { const orders = db.query('SELECT * FROM orders WHERE user_id = ?', req.params.id); res.json(orders); }); // SECURE: Authorization check app.get('/users/:id/orders', (req, res) => { if (req.user.id !== parseInt(req.params.id)) return res.status(403).json({error: 'Forbidden'}); const orders = db.query('SELECT * FROM orders WHERE user_id = ?', req.params.id); res.json(orders); }); ``` **Checklist:** ☐ Authorization on server for all sensitive ops ☐ Default-deny policy ☐ No ID-based obscurity ☐ Whitelist allowed fields --- ### A02: Cryptographic Failures **Detection:** Sensitive data in plaintext; weak encryption (DES, ECB); missing TLS; hardcoded secrets in code. **Mitigation:** Always use HTTPS/TLS; encrypt data at rest with AES-256; store secrets in environment variables or vaults; mask sensitive logs. **Example:** ```python # INSECURE: API key in code api_key = "sk-abc123xyz789" # SECURE: From environment import os api_key = os.getenv("API_KEY") if not api_key: raise ValueError("API_KEY not set") ``` **Checklist:** ☐ HTTPS enforced ☐ AES-256 encryption at rest ☐ No secrets in code ☐ Sensitive data masked in logs --- ### A03: Injection (SQL, Command, NoSQL) **Detection:** String concatenation in queries; `exec`, `query`, `run` with user input; no prepared statements. **Mitigation:** Use parameterized queries; whitelist input; avoid string concatenation; use safe APIs (subprocess.run with list args). **Example:** ```python # INSECURE: String concatenation os.system("tar -czf " + filename + " /var/data") # SECURE: List-based API import subprocess subprocess.run(["tar", "-czf", filename, "/var/data"], check=True) ``` **Checklist:** ☐ Parameterized queries only ☐ No string concat ☐ Whitelist input ☐ Safe subprocess calls --- ### A04: Insecure Design **Detection:** No threat modeling; missing security controls by design; no authentication/authorization from the start. **Mitigation:** Implement threat modeling early; design security in from the beginning; use established security libraries/patterns. **Checklist:** ☐ Threat modeling completed ☐ Security controls in design ☐ Auth/authz from start ☐ Security review in SDLC --- ### A05: Security Misconfiguration **Detection:** Debug mode enabled; default credentials; verbose error messages; missing security headers; exposed APIs. **Mitigation:** Disable debug mode; change defaults; hide version info; implement security headers (HSTS, CSP, X-Frame-Options). **Example:** ```python # INSECURE: Debug enabled in production app.debug = True # SECURE: Debug disabled app.debug = False app.config['HSTS_MAX_AGE'] = 31536000 ``` **Checklist:** ☐ Debug disabled ☐ Defaults changed ☐ Security headers set ☐ No version disclosure --- ### A06: Vulnerable & Outdated Components **Detection:** Old versions in package.json/requirements.txt; unpatched frameworks; deprecated libraries. **Mitigation:** Regularly audit dependencies with `npm audit`, `pip safety`, `Snyk`; remove unused packages; keep frameworks patched. **Checklist:** ☐ Dependency audits regular ☐ No outdated versions ☐ Unused deps removed ☐ CI/CD security scanning --- ### A07: Authentication Failures **Detection:** Weak passwords; no MFA; predictable session IDs; weak password reset tokens; no rate limiting on login. **Mitigation:** Hash passwords (bcrypt/Argon2); implement MFA; generate cryptographically secure session IDs; rate-limit failed attempts. **Checklist:** ☐ Strong password hashing ☐ MFA available ☐ Secure session IDs ☐ Rate limiting on login --- ### A08: Software/Data Integrity Failures **Detection:** Unsigned updates; unverified dependencies; unsafe deserialization (pickle, Java ObjectInputStream). **Mitigation:** Sign and verify all updates; use JSON instead of native serialization; whitelist allowed classes; verify checksums. **Checklist:** ☐ Updates signed/verified ☐ JSON used for serialization ☐ No unsafe deserialization ☐ Checksums verified --- ### A09: Logging & Monitoring Failures **Detection:** No security event logging; logs contain secrets; no centralized logging; no alerts for anomalies. **Mitigation:** Log authentication events, access denials, config changes; centralize logs; implement alerts for suspicious patterns. **Checklist:** ☐ Security events logged ☐ No secrets in logs ☐ Logs centralized ☐ Alerts for anomalies --- ### A10: Server-Side Request Forgery (SSRF) **Detection:** App fetches URLs from user input; no URI validation; internal IP ranges accessible. **Mitigation:** Validate/sanitize URLs; whitelist domains; block internal IP ranges (10.0.0.0/8, 127.0.0.1); use allowlists. **Checklist:** ☐ URLs validated ☐ Domains whitelisted ☐ Internal IPs blocked ☐ Protocols restricted --- ## Section 2: OWASP ASVS 5.0 (Application Security Verification Standard) ASVS defines security requirements across three verification levels (L1: Basic, L2: Standard, L3: Advanced). ### Authentication Requirements | Level | Key Requirements | |-------|-----------------| | **L1** | Password policies (≥8 chars) over HTTPS; brute force protection; identity verification | | **L2** | Strong hashing (bcrypt/Argon2); MFA for sensitive ops; rate-limited login; account lockout | | **L3** | Adaptive authentication; hardware-backed cryptography; step-up auth; comprehensive audit logging | ### Access Control Requirements | Level | Key Requirements | |-------|-----------------| | **L1** | Access control policies enforced; default deny principle; roles/permissions documented | | **L2** | Granular object/property-level controls; privilege escalation detection; token validation per request | | **L3** | Policy/attribute-based access control; cryptographic verification; real-time enforcement; full audit trails | ### Cryptography Requirements | Level | Key Requirements | |-------|-----------------| | **L1** | AES-256 at rest; TLS 1.2+; authenticated encryption mode (GCM/CBC); secure key storage | | **L2** | Key rotation schedule; industry-standard crypto libraries; cryptographically secure RNG; proper KDF | | **L3** | HSM integration; cryptographic agility; perfect forward secrecy; key escrow/recovery | ### Input Validation & Encoding | Level | Key Requirements | |-------|-----------------| | **L1** | Whitelist validation; server-side validation only; proper output encoding; SQL injection protection | | **L2** | Parameterized queries; type/length validation; context-aware encoding; XSS protection | | **L3** | Semantic validation; XXE/XML bomb protection; comprehensive injection defense; cryptographic verification | ### Session Management | Level | Key Requirements | |-------|-----------------| | **L1** | Random session IDs (≥128 bits); HTTP-only/secure flags; session expiration; logout invalidation | | **L2** | Token regeneration post-auth; concurrent session limits; encrypted server-side storage; idle/absolute timeouts | | **L3** | Cryptographic token binding; session fixation protection; anomaly monitoring; tamper detection | --- ## Section 3: OWASP MASVS v2.1.0 (Mobile Security) Mobile applications require specialized security attention due to unique threat models: device-specific vulnerabilities, platform differences (iOS vs Android), and user data sensitivity. **What it is:** MASVS defines 8 control groups with L1/L2/L3 verification levels for mobile app security. **When to use:** Any iOS or Android app security review, secure storage implementation, biometric authentication, network communication hardening. ### Core Control Groups #### **STORAGE** — Protecting Sensitive Data at Rest **L1 Requirements:** - Sensitive credentials never stored in plaintext - Exclude sensitive data from backups - Use platform credential storage APIs **iOS Implementation (Secure):** ```swift import Security func storePassword(account: String, password: String) { let passwordData = password.data(using: .utf8)! let query: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrAccount as String: account, kSecValueData as String: passwordData, kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly ] SecItemAdd(query as CFDictionary, nil) } ``` **Android Implementation (Secure):** ```kotlin import androidx.security.crypto.EncryptedSharedPreferences import androidx.security.crypto.MasterKeys val masterKey = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC) val encryptedSharedPreferences = EncryptedSharedPreferences.create( "secret_shared_prefs", masterKey, context, EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV, EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM ) encryptedSharedPreferences.edit().putString("api_key", "secret").apply() ``` #### **CRYPTO** — Cryptographic Standards **L1 Requirements:** No hardcoded keys, AES-256 for encryption, SHA-256 for hashing **L2 Requirements:** Secure key storage, proper key derivation (PBKDF2), authenticated encryption (GCM mode) **L3 Requirements:** HSM integration, key rotation, cryptographic agility #### **AUTH** — Authentication & Biometric Security **Secure Biometric Implementation (iOS):** ```swift import LocalAuthentication func authenticateWithBiometric() { let context = LAContext() let reason = "Authenticate to access sensitive data" context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reason) { success, error in if success { // Re-authenticate for critical operations KeychainManager.retrieveToken() } } } ``` #### **NETWORK** — TLS & Certificate Pinning **L1 Requirements:** TLS 1.2+ for all communications **L2 Requirements:** Certificate pinning implementation **L3 Requirements:** Mutual TLS (mTLS) support **Android Network Security Config (Secure Pinning):** ```xml <!-- res/xml/network_security_config.xml --> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">api.example.com</domain> <pin-set> <pin digest="SHA-256">+MIIBIjANBgkqhkiG9w0BAQEF...</pin> </pin-set> </domain-config> </network-security-config> ``` #### **PLATFORM** — OS Integration & WebView Security **L1 Requirements:** Validate deep links, secure IPC, WebView hardening **L2 Requirements:** Intent filter verification (Android), Universal Links (iOS) **L3 Requirements:** Sensitive intent filters protected, WebView with JavaScript disabled unless functionally required #### **CODE** — Vulnerable Dependencies & Version Management **L1 Requirements:** Target latest SDK (Android 34+, iOS 15+), scan dependencies **L2 Requirements:** No hardcoded secrets, OTA update verification **L3 Requirements:** Code obfuscation (R8/ProGuard on Android, LinkMap on iOS) #### **RESILIENCE** — Jailbreak/Root Detection **L1 Requirements:** Detect modified environment **L2 Requirements:** Block execution on compromised devices **L3 Requirements:** Continuous monitoring, graceful degradation **Android Root Detection (Secure):** ```kotlin fun isDeviceCompromised(): Boolean { // Check for Magisk if (File("/data/adb/magisk").exists()) return true // Check for SuperUser val suPath = ProcessBuilder("which", "su").start() return suPath.waitFor() == 0 } ``` #### **PRIVACY** — Data Minimization & Privacy Disclosures **L1 Requirements:** Minimal PII collection, privacy policy required **L2 Requirements:** Permission rationale, user consent for data sharing **L3 Requirements:** Privacy by design, differential privacy techniques --- ## Section 4: OWASP API Security Top 10 (2023) — Detailed REST and GraphQL APIs have unique security challenges different from traditional web apps. **What it is:** 10 critical risks specific to API design, authentication, and data exposure. **When to use:** Building or securing REST/GraphQL APIs, token-based authentication, rate limiting, property-level authorization. ### Common API Risks with Examples #### **API1: Broken Object-Level Authorization (BOLA)** **Detection:** Incrementing or predictable IDs in API calls allow access to other users' objects. **Vulnerable Example:** ```javascript // GET /api/orders/123 // Returns all details of order 123, even if user_id != authenticated user app.get('/api/orders/:id', (req, res) => { const order = db.query('SELECT * FROM orders WHERE id = ?', req.params.id); res.json(order); // No authorization check!