Some Random Notes

1.1 OSWAP

13 min read

Q. What is oswap top 10. I need proper obsidian markdown and exhaustive notes on these, which should incluce

  1. what is it
  2. why is it - like how it happens
  3. how to mitigate them, like philosophy behind these
  4. how is it handled in java ecosystem
  5. how is it handled in dot net ecosystem
  6. which of these have been deferred to different components of an application, like which one to handle at api gateway, which at k8 pod etc. Examples should cover real life production based system not analogy

Apart from these i need one quick refresher cheat sheet to refer before interview. Bonus point if it includes mnemonics or such to help me remeber fast. If possible, use callouts and mermaid for this markdown, and if needed obsidian canvas too.

OWASP Top 10 (2025 Edition) - Exhaustive Technical Reference Guide

Architecture Placement Map

The following Mermaid diagram maps out where defenses for each category of the OWASP Top 10 (2025) should ideally reside across a modern cloud-native architecture (Edge, API Gateway, Kubernetes Pod, and CI/CD Pipeline).

Code snippet

graph TD
    Client([Client / User]) -->|HTTPS| Edge[Edge / WAF / Cloudflare]
    
    subgraph Edge Layer
        Edge -->|A02 Misconfig / A05 Injection| Gateway[API Gateway / Ingress]
    end

    subgraph Kubernetes Cluster Pod Layer
        Gateway -->|A01 Access Control & Auth| Pod[Spring Boot / .NET Pod App]
        Pod -->|A04 Crypto & A09 Logging| DB[(Database / Vault)]
    end

    subgraph Supply Chain & Build Pipeline
        CI[GitHub Actions CI/CD] -->|A03 Supply Chain & A08 Integrity| ContainerRegistry[(Container Registry)]
        ContainerRegistry --> Pod
    end

    style Edge fill:#f9f,stroke:#333,stroke-width:2px
    style Gateway fill:#bbf,stroke:#333,stroke-width:2px
    style Pod fill:#bfb,stroke:#fff,stroke-width:2px
    style CI fill:#ff9,stroke:#333,stroke-width:2px

Exhaustive Breakdown of OWASP Top 10 (2025)

A01:2025 - Broken Access Control (Includes SSRF)

What is it?

Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to unauthorized functionality or data, such as accessing other users’ accounts, viewing sensitive files, modifying data, or executing Server-Side Request Forgery (SSRF).

  • Why / Root Cause:
    • Developers rely heavily on client-side enforcement, obscure URLs, or forget to apply explicit authorization checks per request. SSRF happens when an application fetches a remote resource without validating the user-supplied URL, allowing attackers to force the server to connect to internal services (e.g., AWS Metadata services 169.254.169.254).
  • Real-World Production Example:
    • A multi-tenant SaaS banking platform allows users to view statements via /api/v1/accounts?account_id=10492. An attacker simply changes 10492 to 10493 (IDOR - Insecure Direct Object Reference) and successfully dumps another corporate client’s financial statements.
  • Mitigation Philosophy:
    • Never trust the client; assume hostile intent.
      • Adopt a Default Deny architecture where access is explicitly granted per role/permission, and completely isolate internal metadata endpoints via network firewalls.
  • Java Ecosystem Implementation:
    • Spring Security using method-level security (@PreAuthorize("hasRole('ADMIN') and @accountSecurity.hasAccess(#authentication, #accountId)")).
  • .NET Ecosystem Implementation:
    • ASP.NET Core Policy-Based Authorization using custom IAuthorizationHandler and [Authorize(Policy = "OwnsAccount")] attributes.
  • Component Placement:
    • Handled primarily inside the Kubernetes Pod (Application Layer) for business logic/IDOR checks, while generic SSRF protection and IP blocklists can be enforced at the API Gateway/Egress Proxy level.

A02:2025 - Security Misconfiguration

What is it?

Security misconfigurations occur when security controls are incorrectly defined, implemented, or left with default settings (e.g., verbose error messages containing stack traces, unpatched cloud storage buckets with public access, or unnecessary default services enabled).

  • Why / Root Cause: Rapid deployment pressures, complex configuration matrices across multi-cloud environments, and fragmented “Infrastructure as Code” (IaC) scripts.
  • Real-World Production Example:
    • An enterprise e-commerce platform deploys a production Kubernetes cluster where the backend database pod has an open debugging port enabled and exposes internal Spring Boot Actuator endpoints (/actuator/env) publicly, leaking database passwords and secret environment keys.
  • Mitigation Philosophy:
    • Hardened Minimalism.
      • Strip away all default privileges, debug features, and sample files. Treat infrastructure configuration with the exact same rigor as application code (GitOps).
  • Java Ecosystem Implementation:
    • Disabling sensitive Spring Boot Actuators in production via management.endpoints.web.exposure.include=health,info and securing error attributes to suppress stack traces.
  • .NET Ecosystem Implementation:
    • Using environment-specific configurations (appsettings.Production.json) and enforcing secure defaults in Program.cs via if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); }.
  • Component Placement:
    • Enforced continuously via CI/CD Pipelines (IaC Scanning via Trivy/Checkov) and runtime configuration profiles applied at the Kubernetes Pod / Ingress Controller level.

A03:2025 - Software Supply Chain Failures

What is it?

Vulnerabilities arising from compromised third-party dependencies, malicious packages injected into open-source registries, compromised build pipelines, or unverified distribution infrastructure.

  • Why / Root Cause:
    • Modern applications rely on thousands of transitive third-party libraries. Developers pull code from public repositories without verifying code signing, exact cryptographic hashes, or dependency provenance.
  • Real-World Production Example:
    • A FinTech backend incorporates a popular open-source logging library that gets hijacked via a malicious dependency confusion attack, injecting remote code execution payloads into the production build artifact.
  • Mitigation Philosophy:
    • Zero Trust Third-Party Dependencies.
      • Continuously vet, pin, and cryptographically verify all external packages, container base images, and build actions.
  • Java Ecosystem Implementation:
    • Using Maven/Gradle plugins like OWASP Dependency-Check or Snyk to fail builds when a CVE is discovered in pom.xml or build.gradle.
  • .NET Ecosystem Implementation:
    • Using NuGet vulnerability auditing (dotnet list package --vulnerable) integrated directly into MSBuild targets and CI pipelines.
  • Component Placement:
    • Shifted completely left to the CI/CD Pipeline and Software Composition Analysis (SCA) tooling, alongside admission controllers (e.g., Kyverno/OPA Gatekeeper) at the Kubernetes Cluster boundary to block unverified images.

A04:2025 - Cryptographic Failures

What is it?

Failures related to cryptography (or lack thereof) that often lead to sensitive data exposure or system compromise. This includes using weak encryption algorithms, plaintext storage of passwords/tokens, or failing to enforce strict Transport Layer Security (TLS).

  • Why / Root Cause:
    • Legacy codebases implementing custom encryption algorithms (“don’t roll your own crypto”), weak hashing (MD5/SHA1 without salts), or hardcoded API secrets/encryption keys in source code.
  • Real-World Production Example:
    • A healthcare portal stores user passwords using plain MD5 hashes in the database. When a database backup is leaked, attackers instantly crack millions of user passwords via rainbow tables.
  • Mitigation Philosophy:
    • Protect Data at Rest and in Transit.
      • Use industry-standard, computationally expensive modern primitives (Argon2id for passwords, AES-GCM-256 for data at rest, TLS 1.3 for transit).
  • Java Ecosystem Implementation:
    • Utilizing Spring Security’s PasswordEncoder backed by BCryptPasswordEncoder or Argon2PasswordEncoder, and managing keys via HashiCorp Vault or AWS KMS.
  • .NET Ecosystem Implementation:
    • Using ASP.NET Core PasswordHasher<TUser> and leveraging ASP.NET Core Data Protection APIs for encryption keys.
  • Component Placement:
    • Cryptographic enforcement occurs inside the Kubernetes Pod (Application Code) for hashing/encryption, while TLS termination is offloaded to the API Gateway / Load Balancer layer.

A05:2025 - Injection

What is it?

Flaws—such as SQL Injection, NoSQL Injection, Command Injection, and Cross-Site Scripting (XSS)—occur when untrusted data is sent to an interpreter as part of a command or query without proper separation or sanitization.

  • Why / Root Cause:
    • Direct string concatenation of user inputs into database queries, system shells, or dynamic web views. Developers failing to distinguish between code and data.
  • Real-World Production Example:
    • A logistics tracking application builds dynamic search queries by appending user search parameters directly: String query = "SELECT * FROM shipments WHERE tracking_id = '" + userInput + "'";. An attacker submits ' OR '1'='1, dumping the entire table contents.
  • Mitigation Philosophy:
    • Strict Context-Aware Separation of Code and Data.
      • Always use parameterized queries, prepared statements, and safe APIs that handle escaping automatically.
  • Java Ecosystem Implementation:
    • Using JPA / Hibernate Criteria API or JPQL parameters (@Query("SELECT s FROM Shipment s WHERE s.trackingId = :id")) instead of native string queries.
  • .NET Ecosystem Implementation:
    • Using Entity Framework Core (EF Core) LINQ queries which automatically parameterize inputs, preventing raw SQL concatenation.
  • Component Placement:
    • Primarily mitigated at the Application / Pod code level via ORMs/Prepared statements, with basic SQLi/XSS signature payload blocking applied at the Edge Web Application Firewall (WAF).

A06:2025 - Insecure Design

What is it?

A category focusing on risks related to design flaws, representing a call for more use of threat modeling, secure design patterns, and reference architectures. It deals with architectural omissions rather than implementation bugs.

  • Why / Root Cause:
    • Building features quickly without factoring in adversarial mindsets during the architecture phase (e.g., missing multi-step rate limiting on password reset workflows, architectural trust assumptions between microservices).
  • Real-World Production Example:
    • An airline ticketing system designs a password recovery workflow that accepts an email address and immediately returns a password reset token directly in the HTTP response JSON body, ignoring the out-of-band delivery requirement.
  • Mitigation Philosophy:
    • Shift Left via Threat Modeling.
      • Anticipate abuse cases during design sprints using frameworks like STRIDE, and enforce mandatory security design reviews before writing code.
  • Java Ecosystem Implementation:
    • Implementing secure architectural patterns like domain-driven design (DDD) anti-corruption layers, and strict state machine validations for workflow-heavy enterprise apps.
  • .NET Ecosystem Implementation:
    • Utilizing Clean Architecture templates with decoupled domain services and explicit validation pipelines (e.g., FluentValidation integrated into CQRS handlers).
  • Component Placement:
    • Handled during the Software Design Phase / CI/CD Architecture Review Gates, and enforced via architectural constraints within Microservice Mesh policies.

A07:2025 - Authentication Failures

What is it?

=Weaknesses= in confirming a user’s identity, session management, or credential handling. This allows attackers to compromise passwords, keys, or session tokens to assume other users’ identities.

  • Why / Root Cause:
    • Permitting weak passwords, failing to implement multi-factor authentication (MFA), improper session token expiration, or predictable session identifiers.
  • Real-World Production Example:
    • An online banking app issues JWT tokens that lack expiration timestamps (exp) and use weak HMAC-SHA keys, allowing a captured session token to remain valid indefinitely and enabling token forgery.
  • Mitigation Philosophy:
    • Zero Trust Identity.
      • Never assume authentication longevity; mandate strict session lifetimes, secure multi-factor authentication, and robust credential recovery guards.
  • Java Ecosystem Implementation:
    • Spring Security OAuth2 Resource Server validating cryptographically signed RS256 JWTs issued by a secure identity provider (e.g., Keycloak/Okta).
  • .NET Ecosystem Implementation:
    • ASP.NET Core Identity with built-in lockout mechanisms, secure cookie configurations (HttpOnly, Secure, SameSite=Strict), and OpenIddict/Duende IdentityServer integration.
  • Component Placement:
    • Handled at the Identity Provider (IdP) / API Gateway layer for token validation, and within the Kubernetes Pod for internal session verification logic.

A08:2025 - Software or Data Integrity Failures

What is it?

Failures related to code and infrastructure updates, critical data, and CI/CD pipelines without verifying integrity. This includes insecure deserialization or accepting unverified code updates.

  • Why / Root Cause:
    • Trusting serialized objects from untrusted sources, or pipelines that pull artifacts or updates over unverified channels without cryptographic signature verification (checksums/cosign).
  • Real-World Production Example:
    • A microservice parses binary Java serialized objects sent via an HTTP stream from a partner system. An attacker crafts a malicious payload containing gadget chains that triggers remote code execution upon deserialization.
  • Mitigation Philosophy:
    • Verify Everything, Trust Nothing Moving Across Boundaries.
      • Avoid native binary serialization altogether; use safe data serialization schemas (JSON/Protocol Buffers).
  • Java Ecosystem Implementation:
    • Avoiding native java.io.Serializable; implementing safe JSON mappers (Jackson) with strict class-type validations or explicit allow-lists if polymorphism is required.
  • .NET Ecosystem Implementation:
    • Avoiding legacy formatters like BinaryFormatter (completely deprecated); using System.Text.Json or safe JSON settings.
  • Component Placement:
    • Handled in the CI/CD Pipeline (using digital container signing like Cosign) and within the Application Pod data processing layers.

A09:2025 - Security Logging and Alerting Failures

What is it?

Gaps in monitoring, logging, or alerting that let attacks go undetected. Insufficient logging, delayed audit trails, and unmonitored alerts prevent teams from identifying breaches during or after an incident.

  • Why / Root Cause:
    • Developers fail to log security-relevant events (failed logins, high-value transactions, access control failures) or log sensitive data (PII, passwords) into plaintext files, while alerts remain unconfigured.
  • Real-World Production Example:
    • A malicious actor performs a brute-force credential stuffing attack against an e-commerce API over three weeks. Because failed login attempts are not logged or aggregated, security operations never receive alerts.
  • Mitigation Philosophy:
    • Visibility is Defense.
      • Design applications with audit readiness built-in; treat logs as immutable telemetry streams designed for real-time anomaly detection.
  • Java Ecosystem Implementation:
    • Using SLF4J / Logback structured JSON logging, scrubbing sensitive fields via log markers, and streaming logs directly to an ELK stack or Datadog.
  • .NET Ecosystem Implementation:
    • Using Microsoft.Extensions.Logging with structured logging providers, Serilog with contextual enrichment, and Azure Monitor integration.
  • Component Placement:
    • Log generation happens inside the Kubernetes Pod, while collection, routing, and real-time SIEM alerting happen at the Infrastructure/Cluster Logging Operator (Fluentbit/Vector) layer.

A10:2025 - Mishandling of Exceptional Conditions

What is it?

Improper error handling, logical flaws, or insecure failure states—such as failing open during abnormal conditions or leaking internal implementation stack traces to end users.

  • Why / Root Cause:
    • Catching generic exceptions (catch (Exception e)) and returning raw exception details, or writing error handlers that default to permissive access when a database timeout or authentication service outage occurs.
  • Real-World Production Example: When an internal authentication microservice crashes due to high load, the payment gateway application catches the timeout exception and defaults to a “fail-open” status, processing user transactions without verifying authentication tokens.
  • Mitigation Philosophy:
    • Fail Securely.
      • Always fail closed during exceptional states, and abstract error responses away from raw code disclosures.
  • Java Ecosystem Implementation:
    • Global exception handling via Spring @ControllerAdvice and @ExceptionHandler returning standardized, sanitized JSON error responses without stack traces.
  • .NET Ecosystem Implementation:
    • ASP.NET Core middleware (UseExceptionHandler) routing unhandled exceptions to a generic, safe error controller endpoint.
  • Component Placement:
    • Handled universally inside the Kubernetes Pod (Application Framework Error Middleware) and bounded at the API Gateway level to standardize error payloads returned to clients.

Interview Refresher Cheat Sheet & Mnemonics

Use this quick-reference table and memory aid right before your interview to nail down the 2025 OWASP Top 10 list instantly.

The Interview Mnemonic: “A Secure Supply Creates Impressive Designs And Safe Software Logic”

#Category Code & Name1-Sentence DefinitionPrimary Tool / Defense
1A01: Broken Access ControlUsers doing things they aren’t permitted to do / SSRF.Principle of Least Privilege / RBAC
2A02: Security MisconfigurationDefault credentials, open ports, verbose debug errors.Hardening & IaC Scanning
3A03: Software Supply Chain FailuresCompromised libraries, third-party dependencies, bad registries.SCA Tools (Dependency-Check)
4A04: Cryptographic FailuresWeak hashing, plaintext storage, unencrypted data.Argon2 / AES-GCM / TLS 1.3
5A05: InjectionUntrusted data executed as code (SQLi, XSS).Parameterized Queries / ORMs
6A06: Insecure DesignArchitectural flaws and missing secure workflows.Threat Modeling (STRIDE)
7A07: Authentication FailuresWeak passwords, broken sessions, lack of MFA.OAuth2 / OpenID Connect / Secure Cookies
8A08: Software/Data Integrity FailuresUnverified updates, unsafe deserialization, tampering.Digital Signatures & Safe Parsers
9A09: Logging & Alerting FailuresGaps in monitoring that let attacks go undetected.Structured JSON Logging & SIEM
10A10: Mishandling of Exceptional ConditionsFailing open, leaking stack traces, bad error logic.Fail-Closed Error Handlers

Pro Tip for Interviews:

When asked about OWASP Top 10, don’t just recite definitions. State the root cause and explain where you catch it in a cloud-native setup (e.g., “We shift supply chain security left into CI/CD, catch injection at the ORM layer, and handle misconfigurations via automated IaC scanning in our Kubernetes deployment pipelines.”)

Backlinks