160 OWASP Interview Questions and Answers (2026)

OWASP (Open Worldwide Application Security Project) is a nonprofit, community-driven foundation that produces free, vendor-neutral resources, tools, and standards for improving software security.

• What it is:

  • An open community of volunteers who publish guidance, documentation, and open-source tools under free licenses.

  • Nobody owns it commercially, so its advice stays vendor-neutral and widely trusted.

• Why it matters:

  • It gives developers and security teams a shared vocabulary and a baseline for what secure software should look like.

  • Its flagship projects (Top 10, ASVS, Cheat Sheets, ZAP, Dependency-Check) are referenced by regulators, auditors, and standards like PCI DSS.

• Practical impact: Turns abstract 'be secure' goals into concrete, testable requirements teams can build and audit against.

The OWASP Top 10 is a periodically updated awareness document listing the ten most critical web application security risks, meant to be a starting point for security, not an exhaustive checklist.

• Purpose:

  • Raise awareness of the most common and impactful risk categories so organizations prioritize them first.

  • Provide a common reference point for developers, testers, and management.

• It's about risk categories, not single bugs: Each entry groups related weaknesses (mapped to many CWEs) into a broad theme like Broken Access Control.

• Data-driven plus survey: Ranked from aggregated vulnerability data contributed by many firms, supplemented by a community survey for emerging risks.

• A floor, not a ceiling: Addressing the Top 10 is a minimum; deeper assurance uses OWASP ASVS.

The OWASP Top 10 (2021 edition, the current stable list) ranks ten web application risk categories by prevalence and impact.

1. A01 Broken Access Control: users acting beyond their intended permissions.

2. A02 Cryptographic Failures: weak or missing protection of sensitive data (formerly Sensitive Data Exposure).

3. A03 Injection: untrusted input interpreted as commands (SQL, OS, LDAP); now includes XSS.

4. A04 Insecure Design: flaws rooted in missing or weak security design and threat modeling.

5. A05 Security Misconfiguration: insecure defaults, verbose errors, unpatched features.

6. A06 Vulnerable and Outdated Components: using libraries with known flaws.

7. A07 Identification and Authentication Failures: broken login, session, or credential handling.

8. A08 Software and Data Integrity Failures: unverified updates, insecure deserialization, CI/CD tampering.

9. A09 Security Logging and Monitoring Failures: inability to detect and respond to breaches.

10. A10 Server-Side Request Forgery (SSRF): server tricked into making unintended requests.

Common application vulnerabilities are recurring weaknesses in how software handles input, access, configuration, and data, most mapping to OWASP Top 10 categories.

• Injection: SQL injection, command injection, LDAP injection: untrusted input mixed into a query or command.

• Cross-Site Scripting (XSS): Malicious scripts injected into pages viewed by other users (stored, reflected, DOM-based).

• Broken access control: IDOR, missing authorization checks, privilege escalation.

• Authentication and session flaws: Weak passwords, credential stuffing, predictable or unexpired session tokens.

• Cross-Site Request Forgery (CSRF): Tricking an authenticated user's browser into sending unwanted requests.

• Security misconfiguration and outdated components: Default credentials, open cloud buckets, unpatched libraries with known CVEs.

• Sensitive data exposure: Missing encryption in transit/at rest, secrets in code or logs.

OWASP identifies the Top 10 through a mostly data-driven process: it collects real vulnerability data from many organizations, analyzes prevalence, and combines it with a community survey to capture emerging risks not yet visible in the data.

• Open call for data:

  • Security vendors and organizations contribute anonymized findings across hundreds of thousands of applications.

  • Data is organized by CWE to measure how often each weakness appears.

• Ranking factors:

  • Incidence rate (how many apps had at least one instance), plus exploitability and impact.

  • Weaknesses are grouped into root-cause categories rather than individual bugs.

• Community survey:

  • Practitioners vote on risks they see as important but that data lags on (data is backward-looking).

  • Usually a couple of Top 10 slots are filled from this survey.

• Cadence: Updated roughly every 3-4 years to reflect shifting attack trends.

The OWASP Cheat Sheet Series is a free collection of concise, practical, developer-focused guides on how to implement specific security controls correctly. Where the Top 10 tells you what the risks are, the cheat sheets tell you concretely how to defend against them.

• What it contains:

  • Focused documents per topic (e.g. Authentication, Password Storage, SQL Injection Prevention, Input Validation, JWT).

  • Actionable do/don't guidance with code-level recommendations, not high-level theory.

• How you would use it:

  • During design and coding: look up the relevant sheet before implementing a sensitive feature (e.g. read Password Storage before writing a hashing routine).

  • During code review and threat modeling: use it as a checklist to verify controls are done right.

  • Pair it with the Top 10: identify the risk with the Top 10, then apply the matching cheat sheet for the fix.

• Maintained by the community and continuously updated, so it reflects current best practice.

Secure coding practices are the concrete techniques developers apply while writing code to prevent vulnerabilities, treating security as a normal part of correctness. They translate high-level principles into everyday habits at the point where code is written.

• Validate and sanitize input: Use allow-lists, validate type/length/format on the server side, and never trust client data.

• Prevent injection: Use parameterized queries / prepared statements and safe ORM APIs instead of string concatenation.

• Encode output: Context-aware output encoding to stop XSS when data is rendered.

• Handle secrets and crypto correctly: Keep secrets out of source, use vetted libraries, and store passwords with a strong hash like bcrypt or argon2.

• Fail securely and least privilege: Deny by default, don't leak stack traces to users, and log securely without recording sensitive data.

• Reuse trusted components: Prefer established security libraries and keep dependencies patched; consult the OWASP Cheat Sheets for specifics.

Least Privilege means every user, process, or component gets only the minimum access needed to do its job, and no more. Defense in Depth means layering multiple independent controls so that if one fails, others still protect the system. They are complementary: one limits blast radius, the other ensures redundancy.

• Least Privilege:

  • Grant minimal permissions, scoped and time-limited where possible; revoke when no longer needed.

  • Reduces the damage from a compromised account or service (smaller blast radius).

  • Examples: a service DB user with read-only access, containers running as non-root.

• Defense in Depth:

  • Multiple layers: network segmentation, WAF, input validation, authentication, authorization, encryption, monitoring.

  • No single point of failure; an attacker must defeat several controls.

• How they work together:

  • Least Privilege shrinks what a breach can reach; Defense in Depth makes reaching it harder in the first place.

  • Both assume compromise is possible and plan to contain it rather than relying on one perfect barrier.

Least privilege means every user, process, or component is granted only the permissions strictly required to do its job, and no more. This limits the damage an attacker or a bug can cause once a component is compromised.

• Scope of access: Applies to users, service accounts, API tokens, DB accounts, and OS processes alike.

• Grant minimum rights: A read-only reporting service should use a DB account with SELECT only, not full read/write/admin.

• Time-bound and just-in-time: Elevate privileges only when needed and revoke them after, rather than standing admin access.

• Limits blast radius: If a low-privilege component is breached, the attacker inherits only its narrow rights.

• Enforcement in practice:

  • Use role-based access control, drop OS privileges after startup, and avoid running services as root.

  • Review and prune permissions regularly to fight privilege creep.

Access control must be enforced on the server because the client is fully under the attacker's control: any check done only in the browser or app can be bypassed, so the server is the only trustworthy authority on who may do what.

• The client is untrusted:

  • Users can edit JavaScript, disable UI controls, replay requests, or call the API directly with tools like curl or Burp.

  • Hiding a button or a menu is a UX choice, not a security control.

• What goes wrong with client-only enforcement:

  • An attacker crafts the forbidden request directly and the server, trusting the client, executes it.

  • Leads to broken access control: privilege escalation, IDOR (accessing other users' objects by changing an ID), and forced browsing to hidden URLs.

• Correct approach:

  • On every request, verify the authenticated identity and check that it is authorized for that specific resource and action.

  • Deny by default; never rely on the request to tell you the caller's role or ownership.

SQL Injection (SQLi) occurs when untrusted input is concatenated into a SQL query so that attacker-supplied data is interpreted as SQL code, letting an attacker read, modify, or destroy data and sometimes take over the database.

• How it works:

  • The app builds a query by string concatenation, so input like ' OR '1'='1 changes the query's logic instead of being treated as a value.

  • Attackers can bypass auth, dump tables via UNION SELECT, or stack destructive statements.

• Prevention (in order of strength):

  1. Parameterized queries / prepared statements: data is bound separately and never parsed as code (the primary defense).

  2. Use safe ORMs/query builders that parameterize by default.

  3. Input validation and allowlisting for things that can't be bound, like column or table names.

  4. Least privilege DB accounts so a successful injection has limited reach.

  5. Escaping as a last resort, and avoid dynamic query building entirely where possible.

Input validation ensures data entering the application conforms to expected type, format, and range before it's used, which shrinks the attack surface and blocks malformed or malicious input early. Allowlisting (accept only known-good) is far stronger than denylisting (reject known-bad).

• Why it's crucial:

  • Untrusted input is the root of most vulnerabilities (injection, XSS, buffer issues); validating it reduces exploitable paths.

  • It enforces business rules and improves data integrity, not just security.

• Allowlisting (preferred):

  • Define exactly what is acceptable (type, length, pattern, range) and reject everything else.

  • Robust because it fails safe against novel or obfuscated payloads you never anticipated.

• Denylisting (weak):

  • Blocks a list of known-bad patterns, which attackers bypass with encoding or new variants.

  • At best a supplementary layer, never the primary control.

• Key caveats:

  • Always validate server-side; client-side validation is only for UX.

  • Validation is not a substitute for context-specific output encoding and parameterized queries: it complements them (defense in depth).

In OWASP terms, injection is a flaw where untrusted input is sent to an interpreter as part of a command or query, tricking it into executing unintended instructions or returning unauthorized data. It is a long-standing entry in the OWASP Top 10.

• Core mechanism: An interpreter (SQL engine, OS shell, browser, LDAP) can't tell attacker-supplied data from the developer's intended code when the two are concatenated.

• OWASP Top 10 context: In the 2021 list, Injection is category A03 and now includes XSS; it dropped from #1 to #3 as tooling improved but remains widespread.

• Impact: Data theft, data loss, authentication bypass, and in some cases full host compromise.

• General fix: Keep data separate from commands: parameterized APIs, safe libraries, input validation, and context-aware output encoding.

A Web Application Firewall (WAF) is a security layer that inspects HTTP/HTTPS traffic between clients and a web app, filtering or blocking requests that match malicious patterns to protect against common application-layer attacks.

• How it works:

  • Operates at Layer 7, examining request content (parameters, headers, bodies), unlike a network firewall that filters by IP/port.

  • Uses signature/rule-based detection (e.g. OWASP Core Rule Set), and sometimes anomaly/behavioral models, to spot attacks like SQLi and XSS.

• Deployment models:

  • Network/reverse-proxy appliance, host-based module, or cloud-based service.

  • Can run in detection (monitor) or prevention (block) mode.

• Value and limits:

  • Provides virtual patching to buy time before code fixes and reduces exposure to known attack classes.

  • It is a defense-in-depth control, not a substitute for secure code: it can be bypassed and struggles with business-logic flaws.

Yes. OWASP publishes the Web Security Testing Guide (WSTG), a comprehensive, community-driven manual describing how to test the security of web applications and services.

• What the WSTG covers:

  • A structured testing framework and hundreds of specific test cases grouped by category (information gathering, authentication, session management, input validation, business logic, client-side, etc.).

  • Each test explains the objective, how to perform it, and how to interpret results.

• Related OWASP guidance:

  • ASVS: verification requirements you can test against.

  • MASTG/MASVS: the mobile counterparts for app testing.

  • Cheat Sheet Series: focused, practical remediation guidance.

• Use it to: Standardize penetration tests, build repeatable test plans, and ensure coverage across vulnerability classes.

Yes: the OWASP Web Security Testing Guide (WSTG) is the de facto community standard for learning and performing web application security testing, freely available and widely referenced.

• Comprehensive and structured: Covers the full test lifecycle: information gathering, configuration, authentication, authorization, session management, input validation, and more.

• Practical and reproducible: Each test gives objectives, how-to steps, tooling, and remediation, so learners can actually execute and defend the checks.

• Community-maintained and free: Vendor-neutral, regularly updated, and citable in reports and interviews as an authoritative reference.

• Complements other OWASP resources: Pairs well with the ASVS (requirements/what to verify) while WSTG focuses on how to test.

The primary goal of the WSTG is to provide a consistent, repeatable framework of best practices for testing the security of web applications and services.

• Standardize testing: Give testers a common methodology so results are comparable across teams, engagements, and tools rather than ad hoc.

• Improve coverage and quality: A structured checklist reduces the chance of missing categories of vulnerabilities.

• Educate and enable: Teach developers, testers, and security staff how to find and understand weaknesses, with remediation guidance.

• Support secure SDLC integration: Testing can be woven into development rather than treated as a one-off final gate.

The OWASP Mobile Security Testing Guide (MSTG, now the MASTG) is the mobile counterpart to the WSTG: a comprehensive manual for testing the security of iOS and Android applications, paired with the Mobile Application Security Verification Standard (MASVS).

• Platform-specific guidance: Detailed techniques for both Android and iOS: local storage, cryptography, network communication, platform interaction, and code quality.

• Works with the MASVS: MASVS defines the security requirements (what to achieve); the testing guide shows how to verify them.

• Covers mobile-specific threats: Insecure data storage, reverse engineering and tampering, inter-process communication, and anti-reversing controls that web apps don't face.

• Both static and dynamic analysis: Guides decompiling, instrumentation (e.g. with tools like Frida), and runtime testing of the app.

Encryption is reversible (two-way): data is transformed with a key so it can be decrypted back to plaintext, used to keep data confidential. Hashing is one-way: it produces a fixed-length digest that can't be reversed, used to verify integrity or store passwords.

• Encryption:

  • Two-way and key-based; symmetric (one shared key, e.g. AES) or asymmetric (public/private key pair, e.g. RSA).

  • Use when you need to recover the original data: protecting data in transit (TLS), files, or database fields.

• Hashing:

  • One-way and deterministic; same input always yields the same fixed-size digest, and it's infeasible to reverse.

  • Use for integrity checks (checksums, signatures) and storing passwords, where you never need the original back.

  • For passwords, use a slow salted algorithm (bcrypt, Argon2), not fast hashes like SHA-256.

• Key distinction: Encryption preserves confidentiality with recoverability; hashing proves integrity/identity without recoverability. Encoding (e.g. Base64) is neither: it's reversible with no key and provides no security.

Symmetric encryption uses one shared secret key for both encrypt and decrypt; asymmetric uses a mathematically linked key pair (public and private). Symmetric is fast and used for bulk data, while asymmetric solves key distribution and enables signatures, so real systems combine both.

• Symmetric:

  • One key shared by both parties, e.g. AES-GCM; fast and efficient for large volumes.

  • Challenge: securely distributing the shared key.

  • Use for: encrypting data at rest, session traffic, large payloads.

• Asymmetric:

  • Public key encrypts (or verifies), private key decrypts (or signs), e.g. RSA, ECC.

  • Slower, so used on small data; solves key exchange and identity.

  • Use for: key exchange, digital signatures, certificates.

• In practice, hybrid: TLS uses asymmetric crypto to authenticate and agree on a symmetric session key, then encrypts the traffic symmetrically for speed.

They solve different problems: encoding is for data representation (not security), encryption is reversible confidentiality with a key, and hashing is a one-way fingerprint used for integrity or verification.

• Encoding:

  • Transforms data into another format for safe transport/storage (e.g. Base64, URL encoding).

  • Fully reversible by anyone, no key, no secrecy: not a security control.

• Encryption:

  • Reversible transformation using a key to provide confidentiality.

  • Symmetric (shared key, e.g. AES) or asymmetric (public/private, e.g. RSA,); only key holders can decrypt.

• Hashing:

  • One-way function producing a fixed-size digest (e.g. SHA-256); cannot be reversed to the input.

  • Used for integrity checks and password verification (with salting via bcrypt/Argon2).

• Key distinction: encoding = readability, encryption = confidentiality (reversible with key), hashing = verification (irreversible).

Because cryptography is extraordinarily easy to get subtly wrong, and a flaw that is invisible in testing can silently destroy all security; use vetted, peer-reviewed libraries and standards instead.

• Subtle failures are catastrophic:

  • Working encrypt/decrypt code can still be trivially breakable; correctness doesn't imply security.

  • Side channels (timing, padding oracles) leak keys without any obvious bug.

• Requires deep expertise: Secure IV/nonce handling, key management, padding, and constant-time comparison are all easy to botch.

• Vetted libraries are battle-tested:

  • Standard algorithms and libraries (e.g. libsodium, Tink, platform crypto APIs) are reviewed by experts and patched.

  • Prefer high-level, misuse-resistant APIs that pick safe defaults for you.

• Rule: use proven primitives and let experts do the algorithm design; your job is correct integration, not invention.

Authentication (AuthN) verifies who you are; authorization (AuthZ) determines what you are allowed to do. Authentication always comes first, then authorization decisions are made based on that identity.

• Authentication (AuthN):

  • Proves identity via credentials (password, token, biometrics, MFA).

  • Answers: "Are you who you claim to be?"

• Authorization (AuthZ):

  • Grants or denies access to resources/actions based on roles, permissions, or policies.

  • Answers: "Are you allowed to do this?"

• Order and dependency:

  • AuthN precedes AuthZ; you can't authorize an unidentified subject.

  • Common flaw: authenticating a user but failing to enforce per-object authorization (Broken Access Control, e.g. IDOR).

Multi-factor authentication (MFA) requires two or more independent proofs of identity from different categories, so a stolen password alone is not enough to log in.

• The three factor categories:

  • Something you know (password, PIN).

  • Something you have (phone, hardware token, passkey device).

  • Something you are (fingerprint, face).

• Why it reduces risk so much: An attacker must compromise two independent channels, which defeats the most common attacks: credential stuffing, phishing of a single password, and database leaks.

• Not all factors are equal: SMS OTP is phishable and vulnerable to SIM-swap; TOTP apps are better; phishing-resistant WebAuthn/FIDO2 passkeys are strongest because they bind to the origin.

• Watch for: MFA fatigue (push-bombing), weak recovery/reset flows that bypass MFA, and independence: a second factor on the same compromised device adds little.

Verbose errors and stack traces leak internal implementation details to attackers, turning a benign error into reconnaissance that speeds up exploitation. This is why OWASP treats it as a Security Misconfiguration issue.

• They disclose internal information: Stack traces reveal frameworks, library versions, file paths, class names, and SQL, helping an attacker fingerprint and target known vulnerabilities.

• They aid injection and enumeration: Detailed DB errors confirm SQL injection or reveal table/column names; differing messages enable user enumeration.

• Root cause is misconfiguration: Debug mode left on in production (e.g. framework debug flags) exposes traces meant only for developers.

• The fix: Return generic error messages to clients, log full details server-side with a correlation ID, and disable debug mode in production.

A secure SDLC embeds security into every phase of development (requirements, design, coding, testing, deployment) rather than bolting it on at the end, so vulnerabilities are caught early when they are cheapest to fix.

• Cheaper remediation: Fixing a flaw in design or code costs far less than fixing it in production after a breach.

• Fewer vulnerabilities reach production: Threat modeling, secure design reviews, and testing gates remove whole classes of bugs before release.

• Shared security ownership: Security becomes a team responsibility with training and standards, not just a final audit.

• Compliance and auditability: Documented controls and evidence make it easier to satisfy PCI-DSS, GDPR, SOC 2, etc.

• Faster, more predictable releases: Fewer last-minute security surprises and emergency patches disrupting delivery.

A vulnerability assessment is broad and automated: it identifies and catalogs as many weaknesses as possible, while a penetration test is narrow and manual: it actively exploits weaknesses to prove real-world impact.

• Vulnerability assessment:

  • Goal: find and list vulnerabilities across a wide surface (breadth over depth).

  • Mostly automated scanning, run frequently, produces a prioritized inventory.

  • Doesn't confirm exploitability, so it can include false positives.

• Penetration testing:

  • Goal: exploit vulnerabilities to demonstrate real impact and chain weaknesses together (depth over breadth).

  • Manual, human-driven, done periodically, includes business-logic and creative attacks.

  • Proves what an attacker could actually achieve, reducing false positives.

• Relationship: Assessments are often the first step; pen testing validates and prioritizes the findings that truly matter.

DevOps unifies development and operations to deliver software fast and reliably; DevSecOps extends that culture by making security a shared, automated responsibility built into every stage rather than a gate at the end.

• DevOps focus:

  • Collaboration, automation (CI/CD), and fast feedback to ship features quickly and reliably.

  • Optimizes primarily for speed, quality, and stability.

• DevSecOps focus:

  • Adds security as a first-class concern woven into the pipeline ("security as code").

  • Automated scanning, policy checks, and threat modeling happen continuously, not just before release.

• Ownership shift: In DevOps, security is often a separate team; in DevSecOps, security is everyone's responsibility.

• Goal alignment: DevSecOps aims to deliver fast AND secure, catching vulnerabilities early when they are cheap to fix.

"Shift security left" means moving security activities earlier in the software lifecycle (design and coding) instead of treating them as a final gate before release, so defects are caught when they are cheapest and easiest to fix.

• The "left" metaphor: Picture the SDLC as a timeline left (plan/design/code) to right (test/deploy/operate); shifting left pulls security toward the start.

• What it involves in practice:

  • Threat modeling and secure design during planning.

  • IDE and pre-commit checks, plus SAST/SCA in CI on every change.

  • Developer security training and secure defaults.

• Why it pays off:

  • Cost to fix rises sharply the later a bug is found, so early detection saves time and money.

  • Faster feedback loops and fewer late-stage surprises before release.

• Caveat: Shifting left does not replace runtime testing (DAST) and production monitoring; it complements them ("shift left, extend right").

Output encoding is the practice of converting user-controlled data into a safe representation for the specific context where it's rendered, so the data is displayed as literal text rather than interpreted as code. It is the primary defense against XSS because it neutralizes characters the browser would otherwise treat as markup or script.

• What it does: Transforms dangerous characters into their harmless equivalents, e.g. < becomes &lt; so the browser renders it, not executes it.

• It is context-sensitive:

  • HTML body, HTML attributes, JavaScript, URL, and CSS contexts each need different encoding rules.

  • The same data placed in a different context (e.g. inside a href vs. HTML text) requires different encoding.

• Encoding vs. sanitization: Encoding preserves the data but makes it inert; sanitization removes/rewrites dangerous parts (needed when you must allow some HTML).

• Best practice: encode at the point of output (when writing into the page), not at input, and let a trusted library or auto-escaping template engine do it.

All three are XSS (untrusted data executing as script in the victim's browser), but they differ in where the payload lives and how it reaches the victim: stored XSS is persisted on the server, reflected XSS is echoed back in an immediate response, and DOM-based XSS never leaves the client.

• Stored (persistent) XSS:

  • Payload is saved server-side (database, comment, profile field) and served to every user who views it.

  • Most dangerous: no interaction needed beyond viewing the page, and it can hit many victims.

• Reflected (non-persistent) XSS:

  • Payload is part of the request (e.g. a query parameter) and immediately reflected into the response.

  • Requires luring the victim to click a crafted link; not stored, so it targets one user per delivery.

• DOM-based XSS:

  • Vulnerability is in client-side JS that reads a source and writes to a dangerous sink; server may never see the payload.

  • Often delivered via the URL fragment (#), so it evades server-side filters and WAFs.

• Key axis: stored vs. reflected is about persistence on the server; DOM-based is about the flaw being purely client-side.

The OWASP Risk Rating Methodology estimates risk as Likelihood × Impact, breaking each into factors you score and average, so severity is based on reasoning rather than gut feeling.

• Core formula: Risk = Likelihood × Impact, each rated Low/Medium/High from underlying factor scores (0-9).

• Likelihood factors:

  • Threat agent factors: skill level, motive, opportunity, size of the attacker group.

  • Vulnerability factors: ease of discovery, ease of exploit, awareness, intrusion detection.

• Impact factors:

  • Technical impact: loss of confidentiality, integrity, availability, and accountability.

  • Business impact: financial damage, reputation, non-compliance, privacy violation.

• Steps and output:

  • Identify the risk, estimate likelihood and impact, combine into an overall severity, then prioritize fixes.

  • It is intentionally customizable: weight factors to fit your business context.

CWE, CVE, and CVSS are complementary standards: CWE names the type of weakness, CVE identifies a specific real-world vulnerability instance, and CVSS scores how severe that vulnerability is.

• CWE (Common Weakness Enumeration):

  • A catalog of weakness types (categories), e.g. CWE-89 SQL injection or CWE-79 XSS.

  • Describes the root-cause class, independent of any single product.

• CVE (Common Vulnerabilities and Exposures):

  • A unique ID for a specific vulnerability in a specific product, e.g. CVE-2021-44228 (Log4Shell).

  • An instance; it is typically classified by one or more CWEs.

• CVSS (Common Vulnerability Scoring System): A 0-10 severity score based on exploitability and impact metrics, used to prioritize patching.

• How they relate: A CVE (the instance) is an example of a CWE (the weakness type) and is rated by a CVSS score (its severity).

The OWASP API Security Top 10 is a dedicated awareness document focused on risks unique to APIs (REST, GraphQL, gRPC), while the main OWASP Top 10 covers web application security broadly. They overlap but the API list zeroes in on failures that show up when clients talk directly to backend endpoints.

• Different scope: The main Top 10 targets full web apps (server-rendered pages, browsers, sessions); the API Top 10 targets machine-to-machine endpoints.

• API-specific categories dominate:

  • Broken Object Level Authorization (BOLA): the #1 API risk, where a user manipulates an ID to access another user's object.

  • Broken Object Property Level Authorization, Broken Function Level Authorization, and Unrestricted Resource Consumption.

• Why a separate list is needed:

  • APIs expose object identifiers and business logic directly, so authorization flaws are the dominant threat rather than things like XSS.

  • There is no browser rendering layer, so many classic web risks matter less.

• Both are awareness documents, not exhaustive standards; use them to prioritize testing and design review.

The 2021 edition restructured categories around root causes rather than symptoms, merged some old items, and added three new categories: Insecure Design, Software and Data Integrity Failures, and Server-Side Request Forgery (SSRF).

• New categories in 2021:

  • A04 Insecure Design: flaws from missing or weak security design and threat modeling.

  • A08 Software and Data Integrity Failures: unverified updates, insecure deserialization, and CI/CD supply-chain risks.

  • A10 Server-Side Request Forgery (SSRF): added from community survey data.

• Renamed and broadened categories:

  • "Broken Access Control" moved to #1 (was #5), reflecting how common it is.

  • "Sensitive Data Exposure" became Cryptographic Failures (focus on the root cause).

  • "Using Components with Known Vulnerabilities" became Vulnerable and Outdated Components.

• Merges:

  • XSS was folded into Injection.

  • XXE was folded into Security Misconfiguration.

• Methodology shift: Eight categories came from data, two from an industry survey to capture emerging concerns testing tools miss.

Insecure Design (A04:2021) is a category of weaknesses that stem from missing or flawed security design, not from an implementation bug. Even perfectly written code can't fix a system that was never designed with the right controls; the mitigation is to build security in from the start via threat modeling and secure design patterns.

• Design flaw vs. implementation bug: A bug is code that behaves wrongly; a design flaw is a control that was never conceived, so it can't be patched by fixing code.

• Mitigations:

  • Threat modeling early: identify assets, actors, and abuse cases before building.

  • Establish a secure development lifecycle with security requirements and design reviews.

  • Use secure design patterns and reference architectures rather than inventing controls.

  • Write abuse/misuse cases and unit/integration tests that exercise them.

  • Enforce business-logic limits by design (e.g. rate limits, resource quotas, segregation of tiers).

Insecure Design is the absence of, or defect in, security controls at the architecture and business-logic level. It manifests when a workflow can be abused as designed, even when every line of code runs exactly as intended.

• Common manifestations:

  • Business logic abuse: a checkout flow that lets a user apply a discount unlimited times because no limit was designed.

  • Missing rate limiting on password reset or OTP, enabling brute force or enumeration.

  • Trusting client-supplied data for critical decisions (e.g. price sent from the browser).

  • Weak account recovery that relies on guessable security questions.

• Why it happens:

  • No threat modeling, so abuse cases were never considered.

  • Security treated as an afterthought bolted on after the design was fixed.

• Key insight: You detect it by asking "how could a malicious user misuse this feature?" not by scanning for coding errors.

Zero trust is a security model that assumes no user, device, or network is inherently trustworthy: every request must be explicitly verified regardless of where it originates. It replaces the old "trusted internal network vs. hostile internet" perimeter model with "never trust, always verify."

• Core assumption: The network is always assumed hostile, so location (inside the firewall) grants no implicit trust.

• Verify explicitly: Authenticate and authorize every request using identity, device posture, and context (not just a source IP).

• Least privilege access: Grant just-in-time, just-enough access; use micro-segmentation to limit lateral movement after a breach.

• Assume breach: Design as if attackers are already inside: monitor continuously, log everything, and contain blast radius.

• Practical building blocks: Strong identity (MFA), device trust, encryption in transit, and per-request policy enforcement rather than one perimeter gate.

Secure design principles are foundational rules for building systems that resist attack by default, rather than bolting on security afterward. They guide architectural decisions so weaknesses are avoided structurally.

• Least privilege: Give each component the minimum rights it needs, nothing more.

• Defense in depth: Layer independent controls so one failure doesn't compromise the whole system.

• Fail securely: On error, default to denying access rather than granting it.

• Secure by default: Ship with the safest configuration out of the box; make users opt into risk.

• Economy of mechanism / keep it simple: Simple designs have a smaller attack surface and are easier to review.

• Complete mediation: Check authorization on every access, not just the first one.

• Separation of duties: Split sensitive operations so no single actor can abuse them alone.

• Don't trust input / minimize trust: Validate all external data and avoid assuming other components are safe.

"Secure by default" means a system's out-of-the-box configuration is the safest one, so users get protection without having to know about or enable security features. Any reduction in security should require a deliberate, informed choice.

• The core idea: Insecure options must be opt-in, never opt-out: users who do nothing should still be safe.

• Configuration examples:

  • No default or blank admin passwords; force a strong one on first use.

  • Debug modes, verbose stack traces, and sample apps disabled in production.

  • Deny-all firewall/CORS policy that you loosen deliberately, not allow-all by default.

• Application examples:

  • Enforce HTTPS and set secure cookie flags (Secure, HttpOnly, SameSite) automatically.

  • New accounts start with the least privileged role.

  • Strong TLS ciphers and modern defaults instead of legacy compatibility.

• Why it matters: Most users never change defaults, so the default IS the security posture for the majority.

Defense in depth is layering multiple, independent security controls so that no single failure exposes the system. If one layer is bypassed, others still stand between the attacker and the asset.

• Why one control isn't enough: Every control can fail (misconfiguration, zero-day, human error); redundancy prevents a single point of failure.

• Layers work across the stack: Network (firewall, segmentation), application (input validation, authZ), and data (encryption at rest, access control).

• Example in practice: Even with a WAF, still validate input, use parameterized queries, and run the DB with least privilege: each catches what the others miss.

• Slows and detects attackers: Multiple hurdles raise the cost of attack and give monitoring/logging more chances to catch intrusions.

• Caveat: Layers should be genuinely independent; stacking similar controls with the same weakness adds little real defense.

Security by design builds protection into the system's architecture using proven controls that hold up even when the design is publicly known. Security by obscurity relies on keeping the mechanism secret, which fails the moment the secret leaks.

• Security by design:

  • Strength comes from sound controls (strong crypto, access control, validation), not secrecy of how they work.

  • Follows Kerckhoffs's principle: a system should stay secure even if everything but the key is public.

• Security by obscurity:

  • Hiding a secret port, an undocumented endpoint, or a homemade "secret" algorithm as the main defense.

  • Brittle: reverse engineering, leaks, or insiders collapse the protection entirely.

• The nuance: Obscurity is acceptable as an extra layer (defense in depth), never as the only or primary control.

"Fail securely" (or "fail closed") means that when something goes wrong, the system defaults to the safe, restrictive state, typically denying access, rather than leaving a door open. Errors should never accidentally grant privileges.

• Default to deny: If an authorization check throws an exception or returns an unexpected value, treat it as "denied."

• Common anti-pattern: Code that returns true or continues on error, granting access when the check itself failed.

• Don't leak on failure: Error responses should be generic; avoid exposing stack traces or internal details that aid attackers.

• Fail-closed vs. fail-open trade-off: Security-critical paths fail closed; some availability-critical systems intentionally fail open, a deliberate risk decision, not a default.

Attack surface is the sum of all points where an attacker can interact with or extract data from a system; minimizing it removes potential entry points so there is simply less to attack and defend.

• Why it matters:

  • Every exposed endpoint, parameter, port, or feature is a candidate vulnerability: fewer of them means fewer things to secure, patch, and monitor.

  • Unused code and features are rarely tested or maintained, so they age into liabilities.

• How to reduce it:

  • Disable or remove unused features, endpoints, and default accounts/samples.

  • Close unnecessary ports and services; expose only what is required.

  • Limit inputs accepted: fewer parameters and stricter formats mean fewer injection paths.

  • Segment the network and apply least privilege so a breach in one area can't reach everything.

  • Trim dependencies: each library adds transitive code you now must trust and patch.

• Mindset: treat every added feature or integration as a security cost, not just a functional gain.

They separate code from data: the SQL structure is sent to the database and compiled first, then user input is bound purely as values, so input can never change the meaning of the query.

• Query structure is fixed ahead of time: The database parses and plans the statement using placeholders (? or :name), so injected SQL syntax is treated as literal data, not commands.

• Input is bound, never concatenated: Values are passed through a separate channel and typed/escaped by the driver, eliminating string-building bugs entirely.

• Superior to manual escaping: Escaping/blocklists miss edge cases, encodings, and dialect quirks; parameterization removes the root cause instead of patching symptoms.

• Caveat: not everything can be parameterized: Table/column names and keywords can't be bound as parameters; validate those against an allowlist.

Injection is a class, not just SQL: any time untrusted input is interpreted by a downstream engine (a shell, a NoSQL query, a browser, an LDAP directory), an attacker can smuggle in commands.

• OS Command Injection: Input reaches a shell call (os.system), so ; rm -rf / or && runs extra commands; avoid the shell and pass args as an array.

• NoSQL Injection: Operators injected into document queries (e.g. {"$ne": null} or $where JavaScript) bypass auth or dump data.

• Cross-Site Scripting (XSS): Injection into an HTML/JS context: attacker script runs in the victim's browser, stealing sessions or acting as the user.

• Other engines: LDAP injection, XPath injection, header/CRLF injection, template injection (SSTI), and expression-language injection all follow the same pattern.

• Common root cause: Mixing untrusted data with an interpreter's syntax; the fix is always context-appropriate separation or encoding.

They are complementary defenses at opposite ends: input validation checks data as it enters (is this well-formed and allowed?), while output encoding makes data safe as it leaves into a specific interpreter (render it as inert text).

• Input validation (at the boundary):

  • Prefer allowlists: constrain type, length, format, range (e.g. an email or numeric ID).

  • Reduces attack surface but is a defense-in-depth layer, not a complete fix: valid data can still be dangerous in some contexts.

• Output encoding (at the sink):

  • Neutralizes special characters for the destination so data is interpreted as data, not code.

  • Context-specific: HTML-encode for HTML body, JS-encode for scripts, URL-encode for URLs.

• Key difference: Validation = filtering what comes in; encoding = safely representing what goes out. Encoding is the actual injection-stopper, validation is the supporting layer.

• Best practice: Use both, plus parameterization for queries; never rely on validation alone to stop injection.

Remote Code Execution is the ability for an attacker to run arbitrary code on a target machine over the network, typically the most severe outcome because it can lead to complete system takeover.

• How it happens: Command injection, insecure deserialization, unsafe use of eval, template injection (SSTI), file upload flaws, or memory-corruption bugs.

• Why it's critical: The attacker runs code with the application's privileges: data theft, lateral movement, persistence, ransomware, or pivoting deeper into the network.

• Typical progression: Gain execution, then escalate privileges, establish a foothold (reverse shell), and move laterally.

• Defenses: Avoid dynamic code execution on input, patch dependencies, run with least privilege, sandbox/containerize, and validate all untrusted input.

XXE is an injection against XML parsers that process external entities: an attacker defines an entity pointing at a local file or URL, and the parser dutifully fetches it, leading to file disclosure, SSRF, or denial of service. The fix is to disable external entity and DTD processing.

• How the attack works: A malicious <!DOCTYPE> declares an entity like SYSTEM "file:///etc/passwd" that the parser resolves and includes in the response.

• Impacts: Local file read, server-side request forgery (SSRF), internal port scanning, and the "billion laughs" entity-expansion DoS.

• Prevention:

  • Disable DTDs and external entities in the parser (safest: turn off DOCTYPE entirely).

  • Prefer less complex formats like JSON when XML isn't required.

  • Patch/upgrade parsers and use secure defaults; validate and sanitize uploaded XML.

Mass assignment happens when a framework automatically binds request parameters directly onto object properties, letting an attacker set fields they were never meant to control (like isAdmin or role) simply by adding them to the payload.

• How it arises: Convenience binders (Rails params, Spring @ModelAttribute, ORMs) map all incoming keys onto the model, including sensitive ones.

• Example: A profile-update form accepts {"name": "...", "role": "admin"} and the extra field silently promotes the user.

• Prevention:

  • Use an allowlist: explicitly bind only permitted fields (Rails strong parameters, DTOs).

  • Map input to a dedicated request/DTO object rather than the persistence entity.

  • Mark sensitive fields as read-only/non-bindable and enforce authorization on who can change them.

Fuzzing is an automated testing technique that feeds a program large volumes of malformed, unexpected, or random inputs to trigger crashes, hangs, or anomalous behavior that reveal bugs.

• How it works:

  • A fuzzer generates or mutates inputs and monitors the target for crashes, assertion failures, memory errors, or exceptions.

  • Coverage-guided fuzzers (e.g. AFL, libFuzzer) use instrumentation to steer inputs toward unexplored code paths.

• Types:

  • Mutation-based: mutate valid sample inputs; dumb but easy to set up.

  • Generation-based: build inputs from a model/grammar of the format; smarter but needs effort.

• Best suited for:

  • Memory-safety bugs in native code: buffer overflows, use-after-free, out-of-bounds reads/writes.

  • Robustness/parsing flaws: crashes and hangs (DoS) in file parsers, protocol handlers, and input validators.

• Limitation: great at finding crash-triggering input bugs, but poor at logic flaws, access-control errors, or vulnerabilities that need semantic understanding.

OWASP ESAPI (Enterprise Security API) is a free, open-source library of security control components that developers can call instead of writing their own, aiming to make secure coding easier and more consistent.

• What it provides:

  • Reusable controls for input validation, output encoding, authentication, access control, encryption, and logging.

  • For example, encoding APIs to prevent XSS and validators to reject malformed input.

• Goal: Centralize security logic so developers avoid re-implementing (and misimplementing) common defenses.

• Status caveat: The Java version is the most mature, but ESAPI is largely legacy and less actively maintained; modern projects often prefer purpose-built libraries (e.g. framework-native encoding, dedicated crypto libs).

WebGoat and WebScarab are two OWASP training/testing projects: WebGoat is a deliberately insecure application for learning to exploit and fix vulnerabilities, while WebScarab was an intercepting proxy for analyzing HTTP(S) traffic.

• WebGoat:

  • An intentionally vulnerable Java web app with guided lessons on flaws like SQL injection, XSS, and access control.

  • A safe, legal environment to practice attacks and understand remediations hands-on.

• WebScarab:

  • A proxy that sits between browser and server to intercept, inspect, and modify requests and responses.

  • Now largely legacy/deprecated; superseded by OWASP ZAP for the same intercepting-proxy role.

Both are OWASP tools that tackle vulnerable third-party components (Software Composition Analysis): Dependency-Check scans a project's dependencies for known vulnerabilities, and Dependency-Track continuously monitors an inventory of components across many applications over time.

• The problem they solve: Modern apps are mostly third-party code; known-vulnerable libraries (the OWASP category Vulnerable and Outdated Components) are a top risk that manual review can't keep up with.

• OWASP Dependency-Check:

  • A scanner (CLI, Maven/Gradle plugins, CI) that identifies dependencies and maps them to published vulnerabilities using CPE identifiers against sources like the NVD.

  • Best run per-build to fail or flag a pipeline when a risky component is present.

• OWASP Dependency-Track:

  • A platform that ingests a Software Bill of Materials (typically CycloneDX SBOMs) and continuously re-evaluates it as new vulnerabilities are disclosed.

  • Gives portfolio-wide visibility: which applications use a newly vulnerable component, plus policy and alerting.

• How they relate: Dependency-Check is point-in-time scanning at build; Dependency-Track is ongoing monitoring of an inventory. Many teams use both.

Threat modeling is a structured process of identifying, analyzing, and prioritizing potential threats to a system early in design, so you can build in defenses before code ships rather than patching after an incident.

• What it involves:

  • Typically answers four questions: What are we building? What can go wrong? What are we doing about it? Did we do a good enough job?

  • Uses aids like data flow diagrams, trust boundaries, and frameworks such as STRIDE or attack trees.

• Why it matters:

  • Shift-left economics: fixing a design flaw on a whiteboard is far cheaper than fixing it in production.

  • Finds design-level flaws (missing trust boundaries, weak authz) that scanners and pen tests often miss.

  • Prioritizes effort: focuses defenses and testing on the highest-risk assets and flows.

  • Builds shared understanding among developers, security, and architects and documents design decisions.

• Key point: It's an iterative activity, not a one-time document: revisit it as the architecture evolves.

A data flow diagram (DFD) models how data moves through a system, and it's the foundational picture for threat modeling because it exposes where data crosses trust boundaries, which is where most threats arise.

• Core elements:

  • External entities: users or systems outside your control that produce/consume data.

  • Processes: components that transform data (e.g. an API, a service).

  • Data stores: where data rests (databases, files, caches).

  • Data flows: arrows showing data moving between the above.

• Trust boundaries: Drawn where the level of trust changes (e.g. internet to server, app to database); crossings are prime spots to scrutinize.

• Why it helps threat modeling:

  • You can walk each element and flow and apply STRIDE to ask what could go wrong at that point.

  • Uses leveled detail: a context (level 0) diagram, then decompose into more granular levels as needed.

Good threat modeling is structured, collaborative, and continuous: it asks what you're building, what can go wrong, what you'll do about it, and whether you did a good job (Shostack's four questions).

• Start with a clear scope and model: Draw data flow diagrams, mark trust boundaries, and identify assets and entry points before enumerating threats.

• Use a framework, not guesswork: Apply STRIDE, attack trees, or PASTA to systematically find threats instead of relying on intuition.

• Make it a team sport: Include developers, architects, security, and product so you capture real design knowledge and shared ownership.

• Prioritize by risk: Rank threats (impact x likelihood) and focus mitigations where they matter; don't try to fix everything equally.

• Do it early and often: Model during design and revisit on significant change; it's cheapest to fix before code is written.

• Make it actionable and traceable: Record threats, decisions, and mitigations as tracked work items, and validate them with tests or pentests.

Cryptographic Failures (OWASP A02) occur when sensitive data is not properly protected due to missing, weak, or misused cryptography, leading to exposure of data like credentials, PII, or payment information. It was formerly named "Sensitive Data Exposure," which described the symptom; the new name points at the root cause.

• Common failures:

  • Transmitting or storing sensitive data in cleartext (no TLS, unencrypted database fields).

  • Using weak or deprecated algorithms (MD5, SHA-1, DES) or weak key sizes.

  • Poor key management: hardcoded keys, no rotation, keys in source control.

  • Misuse: reusing IVs/nonces, ECB mode, weak randomness from non-cryptographic RNGs.

• Mitigations:

  • Classify data and encrypt sensitive data in transit (TLS 1.2+) and at rest.

  • Use strong, current algorithms (e.g. AES-256-GCM) and authenticated encryption.

  • Store passwords with a strong adaptive hash (bcrypt, scrypt, Argon2) plus a salt, never plain encryption.

  • Manage keys properly (KMS/HSM, rotation, least privilege) and use a CSPRNG.

  • Don't store data you don't need, and disable caching of sensitive responses.

Cryptographic Failures are weaknesses where cryptography is missing, weak, or wrongly applied, leading to exposure of data that should be confidential or tamper-evident. They apply to data both in transit and at rest, and often stem from configuration and design errors as much as broken algorithms.

• No encryption where it's needed: Sensitive data (passwords, PII, tokens, card data) sent or stored in cleartext, e.g. plain HTTP.

• Weak or deprecated primitives: Using MD5, SHA1, DES, or ECB mode when strong modern options exist.

• Bad key and secret management: Hardcoded keys, reused IVs/nonces, keys in source control, or no rotation.

• Improper password storage: Fast hashes or unsalted hashes instead of bcrypt, scrypt, or Argon2.

• Misconfigured transport security: Old TLS versions, weak cipher suites, disabled certificate validation, or missing HSTS.

• Weak randomness: Using non-cryptographic PRNGs (like random) for tokens or keys.

Weak or outdated algorithms give a false sense of security: they can be broken with practical effort, letting attackers forge data, recover plaintext, or impersonate parties. Because the API "works," the weakness is invisible until exploited, which makes it especially dangerous.

• Broken hash functions:

  • MD5 and SHA1 are vulnerable to collisions, so integrity and signature guarantees can be forged.

  • Fast hashes for passwords enable cheap brute-force cracking.

• Weak ciphers: DES/3DES and RC4 have small key sizes or known biases, allowing plaintext recovery.

• Obsolete protocols: SSLv2/v3, TLS 1.0/1.1 are subject to attacks like POODLE and BEAST; require TLS 1.2+ (ideally 1.3).

• Downgrade attacks: If weak options remain enabled, attackers can force negotiation down to them even if strong ones exist.

• Compliance and trust impact: Regulations (PCI-DSS, etc.) prohibit deprecated crypto, so use exposes you to legal and reputational risk.

You protect data in transit with strong, correctly configured TLS everywhere, and data at rest with encryption using vetted algorithms and well-managed keys. The goal is confidentiality and integrity across the whole data lifecycle, backed by classification so you know what actually needs protecting.

• In transit:

  • Enforce TLS 1.2+ with strong cipher suites; redirect HTTP to HTTPS and set HSTS.

  • Validate certificates properly; encrypt internal service-to-service traffic too, not just the edge.

• At rest:

  • Use authenticated encryption like AES-256-GCM for databases, files, and backups.

  • Store passwords with a slow, salted hash: Argon2, bcrypt, or scrypt.

• Key management: Keep keys in a KMS/HSM or secrets manager, never in code; rotate and scope them.

• Data classification and minimization: Know what's sensitive, encrypt accordingly, and don't store what you don't need.

• Caveat: Encryption at rest doesn't protect data once the app has decrypted it; combine with access control.

Never store plaintext or plain hashes: store passwords using a slow, salted, adaptive password-hashing function so that even a database breach doesn't easily reveal credentials.

• Use a dedicated password hash: Prefer Argon2id (or scrypt/bcrypt); never MD5 or raw SHA-256, which are too fast.

• Salt every password: A unique random salt per user defeats rainbow tables and prevents identical passwords hashing alike (modern libraries handle this automatically).

• Tune the work factor: Set cost/memory parameters high enough to be slow for attackers but acceptable for login; revisit as hardware improves.

• Optional pepper: A secret key stored outside the DB (in a vault/HSM) adds defense if the database alone is stolen.

• Verify in constant time and enforce good hygiene: MFA, rate limiting, and breached-password checks.

Reduce the risk by generating strong, unpredictable session identifiers, protecting them in transit and storage, expiring them aggressively, and layering strong authentication like MFA on top.

• Strong session IDs:

  • Long, high-entropy, generated by a vetted framework CSPRNG; never predictable or sequential.

  • Regenerate the ID on privilege change (login) to prevent fixation.

• Protect the session token: Use cookies with HttpOnly, Secure, and SameSite; enforce HTTPS everywhere.

• Expire and invalidate: Idle and absolute timeouts; destroy sessions server-side on logout.

• Strengthen authentication: MFA, rate limiting/lockout on login, and secure password storage reduce credential-based takeover.

• Follow standards: rely on mature session frameworks rather than custom token schemes.

Secure cookies by restricting how they're transmitted and accessed: set the security attributes so scripts can't read them, they only travel over HTTPS, and they aren't sent on cross-site requests.

• Key attributes:

  • HttpOnly

  • Blocks JavaScript (document.cookie) from reading it, mitigating token theft via XSS.

• Secure: Cookie is only sent over HTTPS, preventing interception on plaintext connections.

• SameSite: Strict or Lax limits sending on cross-site requests, mitigating CSRF.

• Scope and lifetime: Set narrow Domain/Path and reasonable Expires/Max-Age; consider a __Host- prefix to lock scope.

• Store minimal data: keep only an opaque session reference in the cookie, never sensitive info.

Session fixation is an attack where the attacker sets or knows a victim's session ID before login, then hijacks the authenticated session after the victim logs in with that same ID. The primary fix is to regenerate the session ID upon authentication.

• How the attack works:

  • Attacker obtains a valid session ID and tricks the victim into using it (e.g. via a crafted URL or a cookie they set).

  • If the app keeps the same ID after login, the attacker now shares the victim's authenticated session.

• Root cause: The session identifier is not rotated when the privilege level changes (anonymous to authenticated).

• Countermeasures:

  1. Regenerate the session ID on login and on privilege change (e.g. session_regenerate_id()).

  2. Only accept session IDs generated server-side; reject client-supplied IDs.

  3. Set cookies with HttpOnly, Secure, SameSite, and enforce session timeouts.

Stateful authentication stores session data server-side and gives the client an opaque reference (a session ID); stateless authentication (e.g. JWT) puts the session state inside a signed token so the server keeps nothing.

• Stateful (server-side sessions):

  • Client holds an opaque ID (cookie); the server looks up the real state in a store (Redis, DB).

  • Security plus: instant revocation (delete the session), no sensitive data on the client.

  • Cost: shared session storage and stickiness/scaling concerns; CSRF matters because cookies are sent automatically.

• Stateless (self-contained tokens):

  • All state travels in a signed token; the server just verifies the signature, so it scales horizontally with no shared store.

  • Security cost: hard to revoke before expiry, larger tokens, and any signing-key or alg mistake compromises everything.

  • Mitigate with short TTLs, refresh tokens, and careful storage (avoid localStorage to reduce XSS theft).

• Rule of thumb: Need immediate revocation and simplicity: stateful. Need scale and cross-service auth: stateless, but engineer revocation deliberately.

Both attack logins at scale, but brute-force guesses many passwords against an account, while credential stuffing replays already-leaked username/password pairs from other breaches, betting on password reuse.

• Brute-force / password spraying:

  • Tries many candidate passwords for one account, or one common password across many accounts (spraying) to dodge lockouts.

  • Defend with: strong hashing to slow offline cracking, rate limiting, exponential backoff, account lockout/throttling, and CAPTCHA on suspicious attempts.

• Credential stuffing:

  • Replays valid credentials leaked elsewhere, so each attempt often succeeds and passwords are already correct: rate limits alone are weaker here.

  • Defend with: MFA (the key control), breached-password checks (e.g. HaveIBeenPwned), device/IP reputation and bot detection, and impossible-travel/anomaly detection.

• Shared defenses: MFA, anomaly monitoring, and not revealing whether the username or password was wrong all blunt both.

Account enumeration is when an application reveals whether a given username or email exists, letting attackers build a list of valid accounts to target. Prevention means making responses identical whether or not the account exists.

• How it leaks: Different messages ("user not found" vs "wrong password"), different HTTP status codes, or timing differences (a real account runs the hash, a missing one returns instantly).

• Login: Return one generic error ("invalid credentials") and normalize timing by hashing a dummy password even when the user doesn't exist.

• Registration: Don't say "email already taken": show a neutral message and send a confirmation email that tells the real owner what happened.

• Password reset: Always respond with the same message ("if that account exists, we've sent a link") regardless of existence, and send the email only to real accounts.

• Cross-cutting: Rate-limit these endpoints and keep response time/shape uniform to close timing side channels.

A secure reset flow proves control of the registered channel using a single-use, short-lived, high-entropy token, without revealing account existence or letting the token be reused or guessed.

• Initiation: Accept the identifier, always show the same neutral response (anti-enumeration), and rate-limit requests.

• Token generation: Use a cryptographically random token (secrets), store only its hash server-side, and set a short expiry (e.g. 15-30 min) plus single-use.

• Delivery: Send the token via the pre-registered email/phone only, never display it in the response or URL log.

• Consumption: Validate the hashed token, enforce a strong new password (breached-password check), then invalidate the token and all existing sessions.

• After the reset: Notify the user out-of-band that their password changed, and re-prompt for MFA rather than letting reset bypass it.

Salting and peppering both harden stored password hashes: a salt is a unique per-password random value stored alongside the hash, while a pepper is a secret value applied to all passwords but kept outside the database.

• Salt:

  • Unique and random per user; not secret, stored with the hash.

  • Defeats precomputed attacks (rainbow tables) and ensures two users with the same password get different hashes.

  • Modern algorithms like bcrypt and Argon2 generate and embed the salt automatically.

• Pepper:

  • A single secret (or HMAC key) applied to every password, stored separately (in a secrets manager or HSM), not in the DB.

  • If only the database leaks, the attacker still lacks the pepper, so hashes are useless without it.

• Why both matter: Salt protects against cross-account and table-based attacks; pepper adds a defense-in-depth secret that a pure DB dump doesn't compromise.

Choose a deliberately slow, memory-hard, adaptive hashing function designed for passwords: prefer Argon2id, then scrypt or bcrypt, and use PBKDF2 mainly where compliance or platform limits require it. The whole point is to make each guess expensive for attackers while staying tolerable for a legitimate login.

• What makes them suitable:

  • They are intentionally slow and tunable (work factor), unlike fast hashes like SHA-256, so attackers can't test billions of guesses per second.

  • They build in per-password salts to defeat rainbow tables.

• Argon2id (preferred): Winner of the Password Hashing Competition; memory-hard, so it resists GPU/ASIC cracking. Tune memory, iterations, and parallelism.

• scrypt: Also memory-hard; a solid choice where Argon2 isn't available.

• bcrypt: Battle-tested and widely supported; note its ~72-byte input limit and that it is not memory-hard.

• PBKDF2: FIPS-approved and ubiquitous, but only CPU-hard, so use a high iteration count; acceptable mainly for compliance-driven contexts.

• Tuning: Calibrate cost so a single hash takes a fraction of a second on your hardware, and raise it over time as hardware improves.

There is no perfect place: cookies (with the right flags) resist XSS token theft but need CSRF defenses, while localStorage is easy to use but fully exposed to any XSS. For browsers, prefer an HttpOnly, Secure, SameSite cookie.

• localStorage / sessionStorage:

  • Read by JavaScript, so any XSS can exfiltrate the token instantly; not sent automatically, so no CSRF risk.

  • Convenient for SPAs and cross-domain APIs where you attach the token in an Authorization header.

• Cookies:

  • With HttpOnly the token is invisible to JavaScript, blunting XSS theft.

  • Sent automatically, so they enable CSRF: mitigate with SameSite=Lax/Strict and/or anti-CSRF tokens.

  • Always add Secure (HTTPS only) and scope with Domain/Path.

• Rule of thumb:

  • Prefer HttpOnly cookies for session/refresh tokens; keep short-lived access tokens in memory if you must use header auth.

  • Never store long-lived tokens in localStorage; a single XSS then equals full account takeover.

Bottom line: the real fix is preventing XSS and CSRF regardless of storage, but cookies with hardening give the strongest default.

Security Misconfiguration (OWASP A05) is the risk from insecure default settings, incomplete hardening, or exposed features across any layer of the stack: servers, frameworks, cloud, containers, and app configs. It is mitigated by hardening, minimizing surface area, and automating consistent configuration.

• Common examples:

  • Default accounts/passwords left enabled, sample apps or admin consoles reachable.

  • Verbose error messages/stack traces leaking internals to users.

  • Unnecessary features, ports, or services enabled; overly permissive cloud storage (public S3 buckets).

  • Missing security headers or disabled TLS.

• Mitigations:

  • Harden with a repeatable baseline: disable defaults, remove unused components, apply least privilege.

  • Use infrastructure-as-code and automated config scanning so all environments match.

  • Return generic error messages; log details server-side only.

  • Set security headers (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options).

  • Patch and review configs regularly as part of CI/CD.

Security Logging and Monitoring Failures (OWASP A09) mean attacks go undetected because security-relevant events aren't logged, alerted on, or retained. It rarely causes a breach directly but hugely increases dwell time and impact. The fix is comprehensive, protected logging plus active monitoring and response.

• What goes wrong:

  • Logins, failures, access-control denials, and high-value actions aren't logged.

  • Logs exist but nobody monitors or alerts on them; no thresholds for anomalies.

  • Logs are locally stored, unprotected, or lack integrity (attackers erase them).

• Mitigations:

  • Log auth events, failures, input validation errors, and sensitive transactions with enough context (user, IP, timestamp).

  • Centralize logs (SIEM) with tamper-resistant, append-only storage and retention.

  • Alert on suspicious patterns and define an incident response plan.

  • Never log secrets/PII in plaintext; ensure logs themselves are access-controlled.

API security means enforcing authentication, authorization, validation, and monitoring on every endpoint, since APIs expose data and logic directly and have their own OWASP API Top 10. The core principle is to never trust the client and to authorize every request at the object and function level.

• Authentication & authorization:

  • Use strong auth (OAuth2/OIDC, signed tokens); validate tokens on every call.

  • Enforce object-level authorization (BOLA/IDOR) and function-level authorization per role.

• Input & output:

  • Validate and sanitize all input against a schema; use allow-lists.

  • Return only needed fields to avoid excessive data exposure.

• Transport & availability:

  • Enforce TLS everywhere.

  • Apply rate limiting and throttling to resist abuse and DoS.

• Operational:

  • Version APIs, remove deprecated/undocumented endpoints (inventory management).

  • Log and monitor for anomalies; use an API gateway/WAF for centralized controls.

File upload vulnerabilities arise when an app accepts and stores user files without properly validating type, content, size, and storage location, potentially leading to remote code execution, XSS, or DoS. Secure handling combines strict validation, safe storage, and never trusting client-supplied metadata.

• Common vulnerabilities:

  • Uploading a web shell (.php, .jsp) into a web-executable directory for RCE.

  • Content-type/extension spoofing: a malicious file disguised with an allowed extension.

  • Path traversal in the filename (../../) overwriting system files.

  • Stored XSS via SVG/HTML, or DoS via huge or zip-bomb files.

• Secure handling:

  • Validate by content (magic bytes), not just extension or Content-Type; allow-list permitted types.

  • Generate a new random filename; never use the client-supplied name; strip path components.

  • Store outside the webroot or in object storage, and serve without execute permissions.

  • Enforce size limits and scan with anti-malware.

  • Serve downloads with Content-Disposition: attachment and correct Content-Type to prevent inline execution.

Effective logging captures enough context to detect, investigate, and respond to security-relevant events, while deliberately excluding sensitive data that would create a new breach if the logs leak. The OWASP category is Security Logging and Monitoring Failures.

• What to capture:

  • Authentication events (success and failure), access-control failures, and privilege changes.

  • Input validation failures, server-side errors, and high-value transactions.

  • Enough context to be useful: timestamp, source IP, user/session ID, action, and outcome.

• What NOT to log:

  • Secrets and credentials: passwords, session tokens, API keys.

  • Sensitive personal/financial data: full card numbers (PCI), health data, or unmasked PII.

• Handling and monitoring: Protect log integrity (append-only, access-controlled), centralize them, and set alerting so events are detected in near real time, not months later.

OWASP ZAP (Zed Attack Proxy) is a free, open-source web application security scanner that sits between your browser and the target as a man-in-the-middle proxy, letting you inspect, modify, and attack HTTP(S) traffic to find vulnerabilities.

• Core role: It acts as an intercepting proxy so you see and manipulate every request/response between client and server.

• Main uses:

  • Manual testing: intercept, tamper, and replay requests.

  • Automated scanning: spider the app to map it, then run passive and active scans to detect issues.

• Where it fits: Used in manual pentests and integrated into CI/CD via its API/headless mode for automated DAST (Dynamic Application Security Testing).

• Nature: It is DAST: it tests a running application from the outside, so it needs no source code.

ZAP splits scanning into passive (observe traffic without altering it) and active (send crafted attacks). Passive is safe and always-on; active is intrusive and must only run against systems you're authorized to test.

• Passive scanning:

  • Analyzes requests/responses that already pass through the proxy without sending new requests.

  • Detects issues visible in traffic: missing security headers, cookie flags, information disclosure.

  • Non-intrusive and safe to run continuously, even in production browsing.

• Active scanning:

  • Sends crafted, malicious payloads to attack known attack surfaces.

  • Detects exploitable flaws: SQL injection, XSS, path traversal, command injection.

  • Intrusive: it can modify data or cause errors, so it requires explicit authorization and ideally a non-prod target.

Spidering is how ZAP discovers the app's URLs and attack surface before scanning. The traditional spider parses HTML links, but the AJAX spider is needed for modern JavaScript apps whose content only appears after the browser renders and interacts with the page.

• Traditional spider:

  • Fetches pages and parses the raw HTML for links and forms, following them recursively to build a site map.

  • Fast, but it does not execute JavaScript, so it misses dynamically generated content.

• AJAX spider:

  • Drives a real browser to render pages and trigger events, discovering URLs created client-side.

  • Essential for Single Page Applications (React, Angular, Vue) where links aren't in the initial HTML.

  • Slower and heavier, so it's typically used alongside the standard spider, not instead of it.

You configure your browser to route traffic through ZAP, capture a request while intercept (break) is on, edit it before it reaches the server, and observe the response: this lets you test how the app handles tampered input.

• Set up the proxy: Point the browser at ZAP's listening port and install ZAP's CA certificate so it can intercept HTTPS.

• Enable interception: Turn on break so ZAP pauses each matching request before forwarding it.

• Tamper the request: Modify parameters, headers, or body (e.g. change a user ID to test IDOR, inject a payload to test XSS/SQLi), then forward it.

• Inspect and replay: Examine the response, and use Request Editor/Manual Request to resend variations without going through the browser.

ZAP tags many of its alerts with the relevant OWASP Top 10 category, so findings roll up into the industry-standard risk framework, though ZAP as a DAST tool covers some categories well and others barely at all.

• Well covered by ZAP:

  • Injection (A03): active-scan payloads detect SQLi, XSS, command injection.

  • Security Misconfiguration (A05): missing headers, verbose errors, default files via passive scan.

  • Broken Access Control (A01): can help find IDOR/forced browsing, often with manual guidance.

• Partially covered:

  • Vulnerable and Outdated Components (A06) and Identification/Authentication Failures (A07): some checks, but not comprehensive.

  • Cryptographic Failures (A02): detects weak TLS/cookie issues but can't see server-side crypto logic.

• Hard for a black-box tool: Insecure Design (A04) and Logging/Monitoring Failures (A09) are largely out of scope: they need design review and code/config visibility.

• Practical note: Use the Top 10 mapping for reporting, but treat ZAP as one input: combine it with SAST, manual testing, and reviews for full coverage.

Broken Access Control is the #1 risk in the OWASP Top 10 (2021): it occurs when an application fails to enforce restrictions on what authenticated users are allowed to do, letting them act outside their intended permissions.

• What it is:

  • Authentication proves who you are; access control (authorization) enforces what you may do. Broken access control is a failure of the latter.

  • Attackers escalate privileges, view other users' data, or reach admin functions they shouldn't.

• Common causes:

  • Relying on the client (hiding a button/URL) instead of server-side checks.

  • Insecure object references (IDOR), missing function-level checks, and forced browsing to unprotected pages.

• How to mitigate:

  1. Deny by default: everything is forbidden unless explicitly granted.

  2. Enforce checks server-side on every request, tied to the authenticated session, never trusting client input.

  3. Enforce ownership: check the resource belongs to the requesting user, not just that they're logged in.

  4. Centralize authorization logic rather than scattering ad-hoc checks; log failures and rate-limit.

  5. Test with automated and manual checks (try accessing other users' IDs and admin routes).

Broken Access Control is when the application does not properly enforce what an authenticated user is permitted to do, allowing users to access data or functionality beyond their authorization. It topped the OWASP Top 10 in 2021.

• Core idea: The policy of who-can-do-what exists but is missing, incomplete, or bypassable at the server.

• Common examples:

  1. IDOR: changing a parameter (/account?id=123) to access another user's record.

  2. Missing function-level control: a normal user calling /admin/deleteUser directly.

  3. Privilege escalation: elevating role via a modified token, cookie, or hidden field.

  4. Forced browsing: reaching unlinked but unprotected URLs.

  5. CORS misconfiguration or metadata tampering (JWT claims, role=admin) to gain access.

• Why it's dangerous: Often trivial to exploit (just edit a URL) yet leads to mass data disclosure or full compromise.

IDOR is a form of broken access control where an application exposes a reference to an internal object (a database ID, filename, or key) and fails to verify that the requesting user is authorized for that specific object, so changing the reference reveals someone else's data.

• The mechanism: The app uses a user-supplied identifier to fetch a resource but only checks that the user is logged in, not that they own the resource.

• How it's exploited:

  1. Attacker observes a reference in a URL or body, e.g. GET /invoices/1001.

  2. They increment/enumerate or swap the value: GET /invoices/1002, and receive another user's invoice.

  3. Works on reads and writes: tampering with an ID on POST/DELETE can modify others' data.

• Where references appear: Query strings, path parameters, hidden form fields, cookies, and JSON bodies.

Both are privilege escalation, but they differ in direction: vertical escalation gains higher-privilege capabilities (user to admin), while horizontal escalation gains access to resources of another user at the same privilege level.

• Vertical privilege escalation:

  • Moving "up" in permissions: a standard user performing admin functions.

  • Example: a regular account reaching /admin/users or setting role=admin in a token.

• Horizontal privilege escalation:

  • Moving "sideways" to a peer's data: same role, different owner.

  • Example: user A reading user B's profile via IDOR (/account/B).

• Why the distinction matters: Vertical is prevented by role/function checks; horizontal is prevented by ownership checks. You need both, since passing one doesn't cover the other.

IDORs occur when an app trusts a user-supplied reference to a resource without verifying ownership. Prevent them by enforcing per-object authorization on the server and avoiding predictable, directly-usable references.

• Enforce authorization per object:

  • On every access, verify the resource belongs to (or is shared with) the current session user, not just that they're authenticated.

  • Scope queries to the user, e.g. WHERE id = ? AND owner_id = :currentUser.

• Reduce reference exposure:

  • Use unpredictable identifiers (UUIDs) so enumeration is harder, but treat this as defense-in-depth, not the primary control.

  • Consider indirect references mapped per-session to real IDs.

• Verify, don't hide: Obscurity alone fails; the server must reject unauthorized references with 403/404.

• Test it: Automated checks that swap IDs between two accounts to confirm access is denied.

Forced browsing is an attack where a user directly requests URLs, files, or resources that are not linked in the UI but are still reachable, exposing unprotected pages. It is a classic manifestation of broken access control.

• How it works:

  • The attacker guesses or enumerates paths (/admin, /backup.zip, /config.old) that were never meant to be public.

  • Tools like dirbusters use wordlists to brute-force common file and directory names.

• Relation to broken access control:

  • The root failure is "security by obscurity": the resource is protected only by not being linked, not by an authorization check.

  • If the server enforced access control on every endpoint, forced browsing would return 403/404 instead of sensitive content.

• Mitigation: Deny by default, require authorization on all resources, and remove stale/backup files from the web root.

Missing function-level access control is when the app fails to restrict access to a sensitive function or endpoint by role/privilege, so a lower-privileged user can invoke privileged operations. Unlike IDOR, which is about accessing a specific object, this is about accessing a whole function or feature you shouldn't.

• Missing function-level access control:

  • The endpoint/action itself isn't gated by role: e.g. a normal user calling POST /admin/promote succeeds.

  • Often caused by only hiding admin links in the UI while leaving the API unprotected (vertical escalation).

• IDOR: The function may be legitimately allowed, but the app fails to check ownership of the specific object referenced (horizontal escalation).

• Key difference:

  • Function-level = "should this user run this action at all?" (role check).

  • IDOR = "is this user allowed to touch this particular record?" (ownership check).

  • Both are broken access control; robust apps enforce both role and ownership on every request.

CSRF tricks an authenticated user's browser into sending an unwanted state-changing request to a site where they are logged in, abusing the fact that browsers automatically attach cookies. Mitigation centers on requiring proof the request came from your own app, not a forged cross-site one.

• How the attack works: A malicious page auto-submits a form or image request to your site; the victim's session cookie rides along, so the server treats it as legitimate.

• Anti-CSRF tokens (synchronizer token pattern): Server issues a random per-session/per-request token; the form must echo it back and the server validates it. The attacker's site can't read it.

• SameSite cookies: Set SameSite=Lax or Strict so cookies aren't sent on cross-site requests, blocking most CSRF.

• Verify origin: Check the Origin / Referer header against an allowlist for sensitive requests.

• Double-submit cookie: Send the token both as a cookie and a request value and compare; useful when server-side session storage isn't available.

• Note: bearer tokens in headers (not cookies) aren't CSRF-prone, since browsers don't auto-attach them.

A preflight is an automatic OPTIONS request the browser sends before certain cross-origin requests, asking the server whether the actual request is allowed. It exists to protect legacy servers by getting permission before any state-changing call is made.

• When it triggers: For non-simple requests: methods like PUT/DELETE, custom headers (e.g. Authorization, X-*), or content types other than the simple form/text ones.

• The exchange:

  • Browser sends OPTIONS with Access-Control-Request-Method and Access-Control-Request-Headers.

  • Server replies with Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Max-Age (how long to cache the approval).

• Security role: Ensures a potentially dangerous cross-origin request is only sent after the server opts in, preventing arbitrary sites from silently invoking sensitive methods.

• Caveat: preflight is a browser convenience/protection, not authentication; the server still must authorize the actual request.

Clickjacking loads your site in an invisible or disguised iframe over attacker content, so a victim's clicks are hijacked to perform actions on your site ("UI redressing"). Both defenses tell the browser whether your page may be framed.

• The attack: An attacker overlays a transparent iframe of your app over a decoy button; the user thinks they click the decoy but actually clicks your app while authenticated.

• X-Frame-Options:

  • Older header with coarse values: DENY (never framed) or SAMEORIGIN (only same-origin framing).

  • Cannot express multiple allowed origins.

• CSP frame-ancestors:

  • Modern replacement: Content-Security-Policy: frame-ancestors 'none' or a list of allowed origins.

  • More flexible and takes precedence over X-Frame-Options in supporting browsers.

• Best practice: set both for coverage, defaulting to deny unless framing is genuinely required.

An open redirect occurs when an app forwards users to a URL taken from untrusted input without validation, letting attackers craft links to your trusted domain that bounce victims to a malicious site (aiding phishing and OAuth token theft).

• Typical pattern: A link like /login?next=https://evil.com where the app blindly redirects to next after login.

• Why it matters: The link starts on your trusted domain, so users and filters trust it; also can leak OAuth codes/tokens.

• Prevention:

  • Prefer relative paths only; reject absolute/external URLs.

  • Validate the destination against an allowlist of permitted URLs/hosts.

  • Use indirect references (map an ID to a known URL server-side) instead of taking the raw URL.

  • If external redirects are unavoidable, show an interstitial warning page.

• Watch for parser tricks: //evil.com, \evil.com, and encoded characters that bypass naive checks.

SameSite is a cookie attribute that tells the browser whether to send a cookie on cross-site requests. By withholding cookies from requests originating on other sites, it removes the automatic credential-attachment that CSRF depends on.

• The three values:

  • Strict: cookie never sent on any cross-site request, even top-level navigation (strongest, but can break inbound links).

  • Lax: sent on top-level GET navigations but not on cross-site subrequests/POSTs (common default, good CSRF balance).

  • None: sent on all cross-site requests, but only allowed with Secure (HTTPS).

• How it mitigates CSRF: A forged cross-site POST from an attacker page won't carry the session cookie under Lax/Strict, so the server rejects it as unauthenticated.

• Limitations:

  • Lax still allows cross-site top-level GETs, so state-changing GETs remain exposed.

  • Browser support/defaults vary; treat it as defense-in-depth alongside anti-CSRF tokens, not a sole control.

The Same-Origin Policy (SOP) is a foundational browser rule that prevents a document or script from one origin (scheme + host + port) from reading data from a different origin. CORS is the controlled exception that lets servers selectively grant cross-origin access.

• What an origin is: The tuple of scheme, host, and port; any difference makes it a different origin (https://a.com vs http://a.com differ).

• What SOP blocks:

  • Reading cross-origin responses, accessing another origin's DOM/cookies/localStorage via script.

  • It does not block sending requests (which is why CSRF exists) or embedding cross-origin resources like images/scripts.

• Relation to CORS: SOP is deny-by-default; CORS is the opt-in mechanism where a server uses Access-Control-Allow-Origin headers to relax SOP for chosen origins.

• Together they let browsers safely support cross-origin APIs while keeping one site from silently reading another's authenticated data.

Secure SDLC means embedding security activities into every phase rather than bolting on testing at the end ("shift left"). The goal is to find and prevent flaws as early and cheaply as possible while building a repeatable, auditable process.

• Requirements & design: Define security requirements and abuse cases; perform threat modeling (e.g. STRIDE) to identify risks before code exists.

• Development:

  • Secure coding standards, developer training, and peer code review with a security lens.

  • Manage dependencies with SCA (Software Composition Analysis) to catch vulnerable libraries.

• Testing / CI-CD: SAST (static analysis) on source, DAST (dynamic) against running apps, and secret scanning, wired into the pipeline to gate builds.

• Release & deployment: Secure/hardened configuration, secrets management, and infrastructure-as-code scanning; penetration testing before major releases.

• Operations & maintenance: Logging/monitoring, patch management, incident response, and a vulnerability disclosure/bug-bounty process.

• Cross-cutting: Use frameworks like OWASP SAMM or ASVS to measure and mature the program; treat findings as feedback into earlier phases.

SAST analyzes source code from the inside without running it (white-box), while DAST tests a running application from the outside like an attacker (black-box); they find different, complementary classes of issues.

• SAST (Static Application Security Testing):

  • White-box: inspects source code, bytecode, or binaries without execution.

  • Runs early in the SDLC (in the IDE or CI), pinpoints the exact file and line.

  • Good at code-level flaws (injection patterns, hardcoded secrets, insecure APIs) but prone to false positives.

• DAST (Dynamic Application Security Testing):

  • Black-box: probes a deployed, running app via HTTP with no code access.

  • Runs later (staging/QA), language-agnostic, finds runtime and config issues.

  • Catches auth, session, and server misconfiguration flaws SAST can't see, but can't point to the source line.

• Bottom line: Use both: SAST for depth in code, DAST for real runtime behavior.

DAST's black-box nature is also its main limitation: it only sees what it can reach at runtime, so it misses code it never exercises and can't tell you where in the code the problem lives.

• No code-level pinpointing: It reports a vulnerable endpoint, not the file/line, so remediation takes longer.

• Late in the SDLC: Needs a running, deployed app, so flaws surface later and cost more to fix than with SAST.

• Incomplete coverage: Only tests reachable paths; unlinked pages, hidden APIs, or unauthenticated-only crawling leave code untested.

• Blind to certain flaw classes: Can't easily find business-logic flaws, hardcoded secrets, or insecure crypto in the source.

• Setup and time cost: Scans can be slow and may need authentication config and a stable test environment to be effective.

You prevent OWASP-class bugs by combining people, process, and tooling: train developers on secure patterns, give them reusable safe defaults, and enforce checks automatically so security isn't dependent on individual memory.

• Education and standards: Regular training mapped to the OWASP Top 10 and secure coding guidelines the team agrees to follow.

• Safe-by-default building blocks:

  • Use parameterized queries/ORMs, output encoding, and vetted frameworks so injection and XSS are hard to introduce.

  • Centralize auth, validation, and crypto in shared libraries instead of ad-hoc per-feature code.

• Automated guardrails in CI/CD: SAST, SCA, and secret scanning on every pull request to catch issues before merge.

• Security-aware reviews: Peer code review with a security checklist and threat modeling for new features.

• Feedback loop: Track recurring bug classes and turn each incident into a lint rule, test, or training update.

Effective secure code review pairs automated scanning to catch the obvious with focused human review of the risky areas, guided by a checklist and threat context rather than a line-by-line read of everything.

• Focus on high-risk areas: Authentication, authorization, input handling, crypto, and anywhere untrusted data crosses a boundary.

• Use a checklist: Map to the OWASP Top 10 so reviewers consistently look for injection, access-control, and misconfig issues.

• Combine tools with human judgment: Let SAST/SCA flag mechanical issues; reserve human effort for business-logic and design flaws tools miss.

• Review with context: Know the feature's threat model and trust boundaries so you evaluate whether controls are actually sufficient.

• Verify, don't assume: Confirm input is validated/encoded, queries are parameterized, secrets aren't hardcoded, and errors don't leak data.

• Keep it constructive and early: Small, frequent reviews on pull requests catch more than one large audit at the end.

DevSecOps rests on integrating security throughout the lifecycle, automating it, and making it a shared cultural responsibility so protection scales with delivery speed.

• Shift left: Address security early in design and coding, not as a late-stage gate.

• Automation: Embed SAST, DAST, SCA, and secrets scanning into CI/CD so checks run consistently without manual effort.

• Shared responsibility: Developers, ops, and security collaborate; security is not siloed.

• Continuous feedback and monitoring: Fast, actionable results to developers, plus runtime monitoring and logging in production.

• Security as code / policy as code: Configurations, guardrails, and compliance rules are versioned and enforced programmatically.

• Least privilege and defense in depth: Layered controls and minimal access reduce blast radius when one control fails.

SAST is "white-box" testing that analyzes source code, bytecode, or binaries without executing them, looking for insecure patterns like injection flaws or hardcoded secrets. It runs early (during coding and CI) so issues are caught before deployment.

• How it works: Inspects code structure, data flow, and control flow statically against a rule set of known vulnerability patterns.

• Advantages:

  • Runs very early, so fixes are cheap; no running app needed.

  • Full code coverage and pinpoints the exact file/line of the flaw.

  • Easy to automate in the IDE and CI pipeline.

• Disadvantages:

  • High false-positive rate, since it lacks runtime context.

  • Cannot find runtime or configuration issues (auth bypass, environment misconfig).

  • Language/framework specific and can be slow on large codebases.

• When to use in the SDLC: During development (IDE plugins) and in CI on every commit/pull request, the leftmost testing stage.

Application-layer rate limiting caps how many requests a client can make in a time window, and anti-automation techniques detect and block bot-driven traffic, protecting endpoints from abuse that a single request wouldn't reveal.

• Rate limiting:

  • Throttles requests per identity (IP, user, API key) using algorithms like token bucket or sliding window.

  • Returns HTTP 429 when a client exceeds the allowed rate.

• Anti-automation: CAPTCHAs, device fingerprinting, proof-of-work, and behavioral analysis to distinguish humans from bots.

• Attacks it defends against:

  • Credential stuffing and brute-force login attempts.

  • Application-layer denial of service (resource exhaustion).

  • Scraping, enumeration of IDs/accounts, and inventory/scalping abuse.

  • OTP/SMS flooding and mass account creation.

• Mapped to OWASP: Addresses the API4:2023 Unrestricted Resource Consumption risk and OWASP Automated Threats.

A bug bounty program invites external security researchers to find and report vulnerabilities in exchange for recognition or monetary rewards, giving organizations continuous crowd-sourced testing. Coordinated (responsible) disclosure is the process by which those findings are reported privately and fixed before public details are released.

• Bug bounty basics:

  • A defined scope, rules of engagement, and reward tiers (often by severity/CVSS).

  • Run in-house or via platforms like HackerOne or Bugcrowd; may be public or invite-only.

• Coordinated disclosure flow:

  • Researcher reports the flaw privately through a defined channel.

  • Vendor acknowledges, triages, and validates the issue.

  • Vendor develops and deploys a fix, agreeing on a disclosure timeline (commonly ~90 days).

  • Details are published publicly (often with a CVE) after the fix, crediting the reporter.

• Why it matters:

  • Contrasts with full disclosure (immediate public release) which pressures vendors but risks exploitation.

  • A safe harbor clause protects good-faith researchers from legal action.

  • A security.txt file signals how to report vulnerabilities.

They differ in scope, depth, and goal: a vulnerability scan is broad and automated, a penetration test actively exploits findings to prove impact, and a red-team engagement simulates a real adversary to test detection and response across the whole organization.

• Vulnerability scan:

  • Automated tool sweep (e.g. Nessus, OpenVAS) that identifies known weaknesses by signature/version matching.

  • Broad but shallow: high false-positive rate, no exploitation, no proof of real impact.

  • Cheap and repeatable; good for continuous coverage.

• Penetration test:

  • Human-driven: a tester actively exploits and chains findings to demonstrate concrete business impact.

  • Scoped and time-boxed (a given app, network, or API); goal is to find and prove as many issues as possible.

  • Usually announced; defenders know it's happening.

• Red-team engagement:

  • Goal-oriented adversary simulation (e.g. reach the crown-jewel data) using any realistic path: phishing, physical, technical.

  • Tests people, processes, and detection/response (the blue team), not just vulnerabilities.

  • Stealthy and often covert; success is measured by objectives met and whether defenders noticed.

• Rule of thumb: scan = what's potentially wrong, pentest = what an attacker could do to a target, red team = whether the org can detect and stop a real attacker.

CSP is a browser security mechanism, delivered via an HTTP response header, that tells the browser which sources of content (scripts, styles, images, etc.) are trusted, so the browser refuses to load or execute anything outside that allowlist. It is a defense-in-depth layer against XSS, not a replacement for output encoding.

• How it's delivered:

  • Sent as the Content-Security-Policy response header (or a <meta> tag) with directives per resource type.

  • Directives like script-src, style-src, default-src define allowed origins.

• How it mitigates XSS:

  • By default it blocks inline scripts (<script>...</script>, onclick=) and eval(), which is how most injected XSS payloads run.

  • Even if an attacker injects a script tag, the browser won't execute it unless it matches the policy.

• Doing it safely:

  • Prefer nonces (nonce-<random>) or hashes to allow specific trusted inline scripts instead of 'unsafe-inline'.

  • Avoid 'unsafe-inline' and wildcards; they gut the protection.

  • Use Content-Security-Policy-Report-Only plus a report endpoint to test before enforcing.

• Limitation: CSP reduces the impact of XSS but doesn't fix the underlying injection flaw; still encode/escape output.

Cross-Site Scripting (XSS) is an injection flaw where an attacker gets malicious JavaScript to execute in another user's browser in the context of a trusted site, letting them steal session cookies, perform actions as the victim, or deface the page. You protect against it primarily with context-aware output encoding, backed by input validation, CSP, and safe framework APIs.

• How it happens:

  • Untrusted input is reflected into a page without proper encoding, so the browser parses it as script rather than data.

  • Runs with the victim's origin, so it can read cookies (document.cookie), make authenticated requests, and manipulate the DOM.

• Primary defenses:

  • Context-aware output encoding when rendering user data (the main control).

  • Use safe framework APIs that auto-escape (e.g. React's default rendering) and avoid innerHTML, eval(), dangerouslySetInnerHTML.

  • Sanitize HTML with a trusted library (e.g. DOMPurify) when rich HTML must be allowed.

• Defense in depth:

  • A strict CSP limits execution of injected scripts.

  • Set cookies HttpOnly so script can't read the session token.

  • Input validation (allowlists) reduces attack surface but is not sufficient alone.

DOM-based XSS is a client-side XSS where the vulnerability lives entirely in the browser's JavaScript: untrusted data flows from a source (like the URL) into a dangerous sink (like innerHTML) without the payload ever needing to be processed or reflected by the server. It differs from reflected and stored XSS in that the injection and execution happen in the DOM, so the server may never see the malicious payload at all.

• Source-to-sink flow:

  • Sources: attacker-controlled inputs like location.hash, document.URL, document.referrer.

  • Sinks: APIs that execute or render data, e.g. innerHTML, document.write(), eval().

• How it differs from reflected/stored:

  • Reflected and stored XSS: the server embeds the payload into the HTML response, so the flaw is server-side.

  • DOM XSS: the payload can live in the URL fragment (#), which browsers never send to the server, so server-side filters and WAFs may miss it entirely.

• Defense:

  • Avoid dangerous sinks; use safe APIs like textContent or setAttribute.

  • Encode/sanitize client-side before writing to a sink; consider Trusted Types (require-trusted-types-for).

SRI is a browser security feature that lets you pin a cryptographic hash of an external script or stylesheet, so the browser refuses to execute it if the fetched content doesn't match: this protects you if a CDN or third-party host is compromised.

• How it works:

  • You add an integrity attribute containing a base64 hash (e.g. sha384-...) to a <script> or <link> tag.

  • The browser hashes the downloaded resource and compares; on mismatch it blocks execution.

• Threat it addresses: A compromised CDN or MITM that swaps in malicious JavaScript is stopped because the modified file no longer matches the pinned hash.

• Requires CORS: The cross-origin resource must be served with crossorigin and proper CORS headers for the integrity check to run.

• Limitations:

  • Only works for static, versioned assets: any legitimate update to the file breaks the hash and must be regenerated.

  • Doesn't help with dynamically generated scripts or resources that intentionally change.

Directory (path) traversal is a vulnerability where attacker-controlled input is used to build a file path, letting them use sequences like ../ to escape the intended directory and read or write arbitrary files on the server.

• How it happens:

  • Code concatenates user input into a filesystem path, e.g. open("/var/files/" + filename).

  • A request like filename=../../../../etc/passwd walks up the tree to sensitive files.

• Impact: Disclosure of config files, source code, credentials, or SSH keys; sometimes file write leading to code execution.

• Evasion tricks to anticipate: URL/double encoding (%2e%2e%2f), absolute paths, and null bytes are used to bypass naive filters.

• Defenses:

  • Avoid using user input in paths; map to an allowlist of IDs instead of raw filenames.

  • Canonicalize the resolved path and verify it stays within the intended base directory before opening.

  • Run with least-privilege filesystem permissions.

HSTS is a response header (Strict-Transport-Security) that tells browsers to only ever connect to a site over HTTPS for a set period, preventing protocol downgrade and SSL-stripping attacks.

• What it does: After receiving the header, the browser automatically rewrites http:// requests to https:// and refuses to allow the user to click through certificate warnings.

• Directives:

  • max-age: how long (seconds) to enforce HTTPS.

  • includeSubDomains: applies to all subdomains too.

  • preload: opts into browsers' hardcoded HSTS preload list, protecting even the very first visit.

• The gap it closes: Without HSTS, the initial plaintext request can be intercepted and downgraded before the redirect to HTTPS; the preload list removes that first-request window.

• Caveat: Must be sent over HTTPS to be honored; misconfigured long max-age with a broken cert can lock users out, so roll it out carefully.

A man-in-the-middle (MITM) attacker intercepts traffic between client and server; you mitigate it primarily by encrypting everything with properly validated TLS and preventing any fallback to plaintext.

• Enforce TLS everywhere:

  • Use HTTPS site-wide with modern TLS versions and strong ciphers; redirect HTTP to HTTPS.

  • Deploy HSTS (ideally preloaded) so browsers never downgrade to plaintext.

• Validate certificates properly:

  • Verify certs and hostnames; never disable certificate validation.

  • For mobile/native clients, consider certificate or public-key pinning.

• Protect cookies and content:

  • Set Secure and HttpOnly on cookies so they only travel over TLS.

  • Use SRI for third-party assets to detect tampered scripts.

• Network hygiene:

  • Keep TLS libraries patched and disable weak protocols (SSLv3, TLS 1.0/1.1).

  • Warn users about untrusted Wi‑Fi; use mutual TLS for sensitive service-to-service links.

HTTP Parameter Pollution (HPP) is supplying the same parameter name multiple times in a request; because servers and frameworks disagree on how to handle duplicates, an attacker can smuggle values past validation or change application logic.

• Why it works: Given ?id=1&id=2, different stacks take the first, the last, or concatenate them (e.g. PHP takes last, some servlets take first, others join with commas).

• Impact:

  • Bypassing input validation or a WAF that only inspects one occurrence.

  • Overriding server-set parameters, tampering with business logic, or feeding a second value into a backend query (aiding injection).

• Where it bites: Especially dangerous when a proxy/gateway validates one interpretation and the backend uses another, or when parameters are forwarded to downstream services.

• Defenses:

  • Explicitly decide and enforce duplicate handling; reject requests with unexpected duplicate parameters.

  • Validate the actual value your code consumes, and use parameterized queries so injected extra values can't alter queries.

These are HTTP response headers that harden the browser's behavior: X-Content-Type-Options stops MIME sniffing, Referrer-Policy controls how much referrer data leaks, and Permissions-Policy restricts which browser features a page may use.

• X-Content-Type-Options: nosniff:

  • Forces the browser to honor the declared Content-Type instead of guessing it.

  • Protects against MIME-sniffing attacks where a file uploaded as text gets executed as script.

• Referrer-Policy:

  • Controls what portion of the URL is sent in the Referer header on outbound requests.

  • Protects against leaking sensitive path/query data to third parties; strict-origin-when-cross-origin is a common safe default.

• Permissions-Policy:

  • Allow-lists powerful features (camera, microphone, geolocation, etc.) per origin.

  • Reduces attack surface and limits abuse if the page is compromised or embeds untrusted iframes.

Vulnerable and Outdated Components (OWASP Top 10 A06) is the risk of running libraries, frameworks, or runtimes with known vulnerabilities or that are no longer maintained, so a public CVE effectively becomes your exploit.

• Why it happens:

  • You don't know all your components or their versions (direct and transitive).

  • Software is out of date, unsupported, or patched slowly; nested dependencies get overlooked.

• Why it's dangerous: Exploits are often public and automated; attackers scan for known-vulnerable versions.

• Mitigation:

  • Maintain an inventory of components and versions (an SBOM).

  • Run continuous SCA scanning against vulnerability feeds (CVE/NVD).

  • Patch and upgrade on a regular cadence; remove unused dependencies and features.

  • Pull only from trusted, signed sources and prefer actively maintained projects.

Software Composition Analysis (SCA) is the automated practice of identifying every third-party and open-source component in your codebase and checking each against known vulnerabilities, licenses, and version data. It's essential because most modern applications are mostly third-party code.

• What it does:

  • Inventories direct and transitive dependencies (from manifests like package-lock.json or pom.xml).

  • Matches them to vulnerability databases (CVE/NVD, GitHub Advisories) and flags risky versions.

  • Detects license risks (e.g. copyleft) that create legal exposure.

• Why it matters:

  • You can't patch what you can't see; SCA gives visibility into code you didn't write.

  • Directly addresses the Vulnerable and Outdated Components risk.

• Best practice: Integrate into CI/CD so builds fail on high-severity findings, and re-scan continuously since new CVEs appear after release.

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component, library, and dependency in an application, including versions and relationships. It's the foundation of vulnerability management: you can only respond to a new CVE quickly if you already know what you ship.

• What it contains:

  • Component names, versions, suppliers, licenses, and dependency hierarchy (direct and transitive).

  • Standard formats include SPDX and CycloneDX.

• Why it matters for AppSec:

  • Rapid impact analysis: when a bug like Log4Shell drops, you query the SBOM to find affected apps in minutes.

  • Supports license compliance and supply chain transparency.

  • Increasingly required (e.g. US Executive Order 14028) for software sold to governments.

• Best practice: Generate it automatically during the build so it stays accurate per release, and feed it into SCA tooling.

The OWASP Top 10 for Agentic Applications is an emerging list addressing security risks unique to AI agents (LLM-driven systems that plan, use tools, and take autonomous actions), where 'least agency' means granting an agent only the minimum autonomy, tools, and permissions it needs.

• Why agents need their own list:

  • Agents don't just process data; they invoke tools, call APIs, and chain actions, so a manipulated prompt can trigger real-world side effects.

  • Attack surface spans prompt injection, tool misuse, memory poisoning, excessive autonomy, and identity/privilege abuse.

• Least agency principle:

  • An extension of least privilege: limit not only permissions but also how much independent decision-making and action an agent may take.

  • Scope its tools tightly, require human approval for high-impact actions, and constrain what it can do without oversight.

• Related controls: Validate and sanitize agent inputs/outputs, sandbox tool execution, log agent actions, and enforce guardrails on chained calls.

The OWASP Top 10 for LLM Applications (GenAI) is an awareness list of the most critical security risks specific to applications built on large language models. It exists because LLMs introduce novel attack surfaces (prompts, training data, model outputs) that traditional lists don't cover.

• Prompt Injection: Attacker-crafted input overrides instructions; can be direct or indirect (hidden in fetched content the model reads).

• Insecure Output Handling: Trusting model output blindly and passing it to downstream systems, leading to XSS, SSRF, or code execution.

• Training Data Poisoning: Tampered training or fine-tuning data introduces backdoors or bias.

• Sensitive Information Disclosure: The model leaks secrets, PII, or proprietary data from its training set or context.

• Other key risks: Model Denial of Service (resource-exhausting prompts), Supply Chain vulnerabilities (third-party models/plugins), Excessive Agency (over-privileged autonomous actions), and Overreliance (users trusting hallucinated output).

Complete mediation means every access to a protected resource is checked for authorization every time, with no shortcuts, cached decisions, or bypass paths. The system must never assume that because access was allowed once, it is still allowed.

• Check on every request: Authorization is re-evaluated for each access, not just at login or first use.

• No bypass routes: All access must funnel through the same enforcement point; alternate APIs or direct object references must be checked too.

• Beware stale caching: Cached permissions can go stale after a role or ownership change; re-verify against current state.

• Common violation: Insecure direct object references (IDOR): the UI hides a resource but the endpoint doesn't re-check ownership on each call.

• Practical enforcement: Centralize authorization in middleware or a policy layer so no handler can forget the check.