Skip to content

Latest commit

 

History

History
324 lines (251 loc) · 35.8 KB

File metadata and controls

324 lines (251 loc) · 35.8 KB
schema_version 1.3
date 2026-04-10
input_format mermaid
classification confidential

Threat Model Report

1. System Overview

Parsed summary of the Mermaid flowchart architecture input depicting a microservices-based e-commerce platform. The system consists of a client application communicating through an API Gateway in the DMZ, which routes requests to internal services (Order Service, Payment Service, Notification Service) backed by dedicated data stores (Order Database, Inventory Database, Message Queue). Payment processing is delegated to an External Payment Provider. Services communicate via synchronous REST calls and asynchronous event-driven messaging through the Message Queue.

Components

Component Type MAESTRO Layer Description
Client Application External Entity L7 — Agent Ecosystem End-user browser or mobile app sending HTTPS requests; resides in the External Clients zone
API Gateway Process L4 — Deployment Infrastructure Single entry point in the DMZ; routes requests, enforces authentication, terminates TLS, and performs service discovery via the Service Registry
Service Registry Process L4 — Deployment Infrastructure Maintains a catalog of service endpoints for dynamic discovery; resides in the DMZ alongside the API Gateway
Order Service Process L2 — Data Operations Manages order creation, validation, and lifecycle; reads/writes to Order Database and Inventory Database; publishes events to Message Queue
Payment Service Process L4 — Deployment Infrastructure Orchestrates payment flow by communicating with the External Payment Provider; publishes payment outcome events to Message Queue
Notification Service Process L4 — Deployment Infrastructure Consumes asynchronous events from Message Queue and delivers email/SMS notifications to the Client Application
Message Queue Data Store L4 — Deployment Infrastructure Asynchronous event bus providing decoupled service-to-service communication for OrderCreated and PaymentCompleted events
Order Database Data Store L2 — Data Operations Persistent storage for order records, order state, and order lifecycle data
Inventory Database Data Store L2 — Data Operations Persistent storage for product catalog and stock levels; queried by Order Service for availability checks and reservations
External Payment Provider External Entity Unclassified Third-party payment processor (e.g., Stripe) handling charge requests and returning payment results; resides in the External Services zone

Data Flows

Source Destination Data Protocol
Client Application API Gateway HTTPS requests (order data, authentication credentials, browsing queries) HTTPS
API Gateway Service Registry Service lookup requests (service name, version) Internal REST
Service Registry API Gateway Endpoint list (host, port, health status) Internal REST
API Gateway Order Service Routed order requests (validated payload) REST/HTTP
API Gateway Payment Service Routed payment requests (validated payload) REST/HTTP
Order Service Order Database Read/write order records (order ID, items, status, timestamps) SQL over TLS
Order Service Inventory Database Stock queries and item reservations (product IDs, quantities) SQL over TLS
Order Service Message Queue Publish OrderCreated events (order ID, items, customer ID) AMQP
Order Service Payment Service Payment requests (order ID, amount, currency) REST/HTTP
Payment Service External Payment Provider Charge requests (tokenized card data, amount, currency, idempotency key) HTTPS
External Payment Provider Payment Service Payment results (authorization code, status, error details) HTTPS
Payment Service Message Queue Publish PaymentCompleted events (order ID, payment ID, status) AMQP
Message Queue Notification Service OrderCreated and PaymentCompleted events AMQP
Notification Service Client Application Email and SMS notifications (order confirmation, payment receipt) SMTP/SMS Gateway

Technologies

Category Technology Version (if known)
Reverse Proxy / Gateway NGINX or Kong-based API Gateway unknown
Service Discovery Consul or Eureka-style Service Registry unknown
Runtime Containerized microservices (Docker/Kubernetes) unknown
Database PostgreSQL (Order Database, Inventory Database) unknown
Message Broker RabbitMQ or Kafka (Message Queue) unknown
Authentication JWT bearer tokens RFC 7519
Transport TLS (HTTPS for external, HTTP for internal REST) unknown
Protocol AMQP (async messaging) unknown
Payment Gateway Stripe or equivalent REST API unknown

2. Trust Boundaries

Trust Zones

Zone Trust Level Components
External Clients Untrusted Client Application
DMZ Semi-trusted API Gateway, Service Registry
Internal Services Trusted Order Service, Payment Service, Notification Service, Message Queue, Order Database, Inventory Database
External Services Untrusted External Payment Provider

Boundary Crossings

Crossing From Zone To Zone Components Controls
Client-to-DMZ External Clients DMZ Client Application -> API Gateway TLS termination, JWT validation, rate limiting, input sanitization
DMZ-to-Internal DMZ Internal Services API Gateway -> Order Service, Payment Service URL-based routing, header stripping, network policy restrictions
Internal-to-DMZ Internal Services DMZ Order Service, Payment Service -> API Gateway (responses) Response filtering, error sanitization
Internal-to-External Internal Services External Services Payment Service -> External Payment Provider HTTPS with API key authentication, idempotency keys, egress filtering
External-to-Internal External Services Internal Services External Payment Provider -> Payment Service (callbacks/results) Webhook signature verification, TLS, IP allowlisting
Cross-Service (Internal) Internal Services Internal Services Order Service <-> Payment Service, Order Service -> Message Queue, Message Queue -> Notification Service Service mesh mTLS, message signing, per-service credentials

3. STRIDE Tables

Risk level computation (OWASP 3x3 matrix):

LOW Likelihood MEDIUM Likelihood HIGH Likelihood
HIGH Impact Medium High Critical
MEDIUM Impact Low Medium High
LOW Impact Note Low Medium

3.1 Spoofing (S)

Threats where an attacker pretends to be something or someone else.

ID Component MAESTRO Layer Threat Likelihood Impact Risk Level Mitigation
S-1 Order Service L2 — Data Operations A rogue process on the internal network impersonates the API Gateway and sends fabricated REST requests directly to the Order Service on its internal port, bypassing all gateway-level authentication and rate limiting controls, enabling unauthorized order creation and data access MEDIUM HIGH High Enforce mutual TLS (mTLS) between all internal services using a service mesh (e.g., Istio, Linkerd); reject any request to the Order Service that does not present a valid client certificate issued by the internal CA; restrict network policies so only the API Gateway can reach the Order Service port
S-2 Payment Service L4 — Deployment Infrastructure An attacker compromises the Service Registry to register a malicious endpoint as the Payment Service, causing the API Gateway to route payment requests containing order amounts and customer identifiers to the attacker-controlled service instead of the legitimate Payment Service HIGH HIGH Critical Implement service identity verification using mTLS certificates tied to service names; digitally sign service registry entries and validate signatures on lookup; deploy health checks that verify service identity before routing; monitor registry for unauthorized endpoint changes
S-3 API Gateway L4 — Deployment Infrastructure Attacker steals or forges JWT tokens to impersonate authenticated users at the API Gateway, placing fraudulent orders or accessing other customers' order history and payment status MEDIUM HIGH High Enforce short-lived JWT expiration (15 minutes); implement token revocation lists synchronized across gateway instances; validate issuer, audience, and signature on every request; use asymmetric signing (RS256/ES256) with regular key rotation
S-4 External Payment Provider Unclassified Attacker performs DNS hijacking or certificate spoofing to intercept payment requests from the Payment Service, redirecting charge requests to a malicious endpoint that captures tokenized card data and returns fabricated success responses LOW HIGH Medium Enforce certificate pinning for the External Payment Provider domain; validate TLS certificates against a known CA bundle; implement payment reconciliation that cross-checks charge results against the provider's dashboard API; alert on certificate fingerprint changes

3.2 Tampering (T)

Threats where an attacker modifies data or code without authorization.

ID Component MAESTRO Layer Threat Likelihood Impact Risk Level Mitigation
T-1 Message Queue L4 — Deployment Infrastructure Attacker with access to the internal network injects forged OrderCreated or PaymentCompleted events into the Message Queue, causing the Notification Service to send false order confirmations and the Payment Service to process fabricated payment requests, creating financial discrepancies across services MEDIUM HIGH High Enable message-level HMAC signing between producers and consumers; enforce per-queue publish ACLs so only the Order Service can publish OrderCreated events and only the Payment Service can publish PaymentCompleted events; restrict network access to the Message Queue broker port
T-2 Order Service L2 — Data Operations Attacker intercepts and modifies REST payloads in transit between the API Gateway and Order Service over unencrypted internal HTTP, altering order quantities, prices, or shipping addresses before the Order Service processes them MEDIUM HIGH High Enforce mTLS for all service-to-service communication within the Internal Services zone; implement request payload signing at the API Gateway with signature verification at the Order Service; deploy a service mesh that encrypts all intra-cluster traffic
T-3 Inventory Database L2 — Data Operations Attacker exploits an over-privileged database service account shared between the Order Service and other internal processes to directly manipulate stock levels in the Inventory Database, creating phantom inventory or depleting stock for competitor sabotage LOW HIGH Medium Apply principle of least privilege: the Order Service account can only execute SELECT and UPDATE on inventory reservation tables; create separate read-only accounts for reporting; enable PostgreSQL audit logging (pgaudit) on all DDL and DML operations; alert on direct SQL modifications outside application patterns
T-4 Payment Service L4 — Deployment Infrastructure Attacker replays or modifies webhook callbacks from the External Payment Provider with altered payment statuses, causing the Payment Service to mark unpaid orders as completed and trigger fulfillment through the downstream event chain MEDIUM HIGH High Verify webhook signatures using the provider's signing secret on every callback; enforce HTTPS-only webhook endpoints with IP allowlisting; implement idempotency keys to prevent replay attacks; cross-validate payment status by querying the provider's API before updating order state

3.3 Repudiation (R)

Threats where an attacker denies having performed an action without the system being able to prove otherwise.

ID Component MAESTRO Layer Threat Likelihood Impact Risk Level Mitigation
R-1 Order Service L2 — Data Operations Customer disputes a legitimate order placement, and the system cannot prove authorization because the Order Service does not capture an immutable audit trail linking the authenticated user identity, source IP, session token, and exact request payload at the moment of order creation MEDIUM MEDIUM Medium Implement append-only audit logging in the Order Service capturing user ID, session ID, source IP, user agent, order payload hash, and timestamp for every order creation and state transition; store audit logs in tamper-evident storage separate from the Order Database
R-2 Notification Service L4 — Deployment Infrastructure Customer claims they never received an order confirmation or payment receipt, and the system cannot prove delivery because the Notification Service does not log message dispatch outcomes with correlation back to the originating Message Queue event and order ID MEDIUM MEDIUM Medium Log all notification dispatch attempts with correlation IDs linking the originating MQ event ID, order ID, notification channel (email/SMS), delivery status, and timestamp; integrate with email/SMS provider delivery receipts; retain delivery logs for the regulatory compliance period
R-3 Payment Service L4 — Deployment Infrastructure A disputed payment transaction cannot be forensically reconstructed because the Payment Service lacks correlation between the internal order ID, the Message Queue event that triggered payment, and the External Payment Provider charge ID, preventing end-to-end audit trail reconstruction MEDIUM HIGH High Log the complete payment lifecycle with correlation IDs linking order ID, MQ message ID, provider charge ID, authorization result, and timestamps at each stage; implement structured logging with a shared trace ID propagated across all services involved in the payment flow

3.4 Information Disclosure (I)

Threats where sensitive data is exposed to unauthorized parties.

ID Component MAESTRO Layer Threat Likelihood Impact Risk Level Mitigation
I-1 Order Database L2 — Data Operations PostgreSQL connection strings or SQL error details containing database credentials are exposed in Order Service error responses propagated through the API Gateway to the Client Application when database queries fail under load MEDIUM HIGH High Implement structured error handling in the Order Service that returns generic error codes to upstream callers; log detailed error context (stack traces, connection strings, query details) to internal-only centralized logging; configure the API Gateway to strip internal error details from all responses crossing the DMZ-to-External boundary
I-2 Message Queue L4 — Deployment Infrastructure Sensitive order data (customer addresses, payment amounts, product details) in transit on Message Queue topics is readable by any internal service with valid AMQP credentials, violating least-privilege access and exposing order data to the Notification Service beyond what it needs for delivery MEDIUM MEDIUM Medium Encrypt sensitive message payloads at the application layer using envelope encryption before publishing; enforce per-queue and per-topic ACLs so each consumer can only read from its designated queues; segregate payment-related messages into a dedicated virtual host with restricted access
I-3 Inventory Database L2 — Data Operations Stock level data and product pricing stored in the Inventory Database is accessible to all internal services sharing a common database credential set, enabling any compromised service to extract competitive business intelligence about inventory positions and pricing strategy MEDIUM MEDIUM Medium Implement per-service database credentials with schema-level access controls; the Order Service account can only access inventory reservation views, not raw pricing tables; encrypt sensitive columns (wholesale pricing, supplier costs) at rest; audit all cross-schema queries
I-4 API Gateway L4 — Deployment Infrastructure Verbose error responses from the API Gateway expose internal service topology information (service names, ports, registry endpoints) to external clients when upstream services are unavailable, enabling attackers to map the internal architecture MEDIUM MEDIUM Medium Configure the API Gateway to return standardized error responses (503 Service Unavailable) with no internal details; log detailed upstream failure context server-side only; implement custom error pages that do not reveal backend service names or network topology

3.5 Denial of Service (D)

Threats where an attacker degrades or prevents legitimate access to the system.

ID Component MAESTRO Layer Threat Likelihood Impact Risk Level Mitigation
D-1 API Gateway L4 — Deployment Infrastructure Volumetric HTTP flood overwhelms the API Gateway's connection pool and TLS handshake capacity, blocking all legitimate client traffic from reaching internal services and causing a complete platform outage HIGH HIGH Critical Deploy upstream DDoS protection (cloud WAF/shield); enforce per-IP and per-user rate limiting at the gateway; implement connection timeouts and request size limits; auto-scale gateway instances behind a load balancer; configure circuit breaker patterns for upstream service failures
D-2 Message Queue L4 — Deployment Infrastructure A malicious or buggy producer floods the Message Queue with high volumes of events, consuming broker memory and disk, triggering flow control that blocks all publishers and halts asynchronous processing across Order, Payment, and Notification services simultaneously MEDIUM HIGH High Configure per-queue message count limits and per-connection publish rate limits; set RabbitMQ memory and disk high watermarks; implement dead-letter exchanges for unprocessable messages; monitor queue depth with automated alerts; implement back-pressure mechanisms in producer services
D-3 Order Service L2 — Data Operations A cascade failure originating from Payment Service unavailability propagates through synchronous REST calls to the Order Service, which exhausts its thread pool waiting for payment responses, rendering the Order Service unable to process any requests including non-payment operations HIGH HIGH Critical Implement circuit breaker patterns (e.g., Hystrix, Resilience4j) on the Order Service's outbound call to Payment Service with configurable timeout, failure threshold, and half-open recovery; implement bulkhead isolation so payment-related thread pools do not starve other Order Service operations; fall back to asynchronous payment processing via Message Queue when the synchronous path is unavailable
D-4 Service Registry L4 — Deployment Infrastructure Attacker floods the Service Registry with deregistration requests or health check failures, causing the API Gateway to lose all service endpoints and return 503 errors for every request, effectively taking the entire platform offline without directly attacking any business service MEDIUM HIGH High Implement authentication and rate limiting on Service Registry management APIs; cache last-known-good service endpoints at the API Gateway with configurable stale-serve TTL; require cryptographic authentication for service registration and deregistration operations; deploy the Service Registry as a replicated cluster with quorum-based consensus

3.6 Elevation of Privilege (E)

Threats where an attacker gains higher access rights than authorized.

ID Component MAESTRO Layer Threat Likelihood Impact Risk Level Mitigation
E-1 API Gateway L4 — Deployment Infrastructure Attacker discovers an undocumented internal-only route on the API Gateway that bypasses JWT validation and exposes administrative endpoints (service registry management, rate limit configuration, health check overrides) to unauthenticated external requests LOW HIGH Medium Audit all API Gateway routes and enforce authentication on every endpoint including health and admin paths; implement route allowlisting where only explicitly declared public routes bypass authentication; perform regular gateway configuration reviews; deploy automated route scanning in CI/CD
E-2 Order Service L2 — Data Operations Attacker manipulates order status transitions by sending crafted REST requests that bypass the Order Service's state machine validation, advancing orders from "pending_payment" to "fulfilled" without completing payment, enabling order fulfillment fraud MEDIUM HIGH High Implement a strict finite state machine for order lifecycle transitions that validates the current state, the requested transition, and the authenticated caller's role before allowing any state change; reject all invalid transitions with explicit error responses; log all state change attempts including denied transitions for audit
E-3 Payment Service L4 — Deployment Infrastructure Attacker exploits the lack of per-service authorization boundaries to call the Payment Service directly on its internal port (bypassing the API Gateway), issuing refund requests or modifying payment records without customer or administrator authorization MEDIUM HIGH High Enforce network policies that restrict Payment Service port access to only the API Gateway and authorized internal callers (Order Service); implement service-level authorization checks that validate caller identity via mTLS certificates regardless of network path; require separate authorization tokens for refund operations with elevated approval requirements
E-4 Notification Service L4 — Deployment Infrastructure Attacker compromises the Notification Service through a deserialization vulnerability in event consumption and pivots to access the Message Queue broker credentials stored in the service's configuration, gaining the ability to publish arbitrary events to any queue and impersonate any producer service LOW HIGH Medium Apply least-privilege credentials: the Notification Service's Message Queue account should only have consume permissions on its designated queues with no publish access; store broker credentials in a secrets manager (not configuration files); implement input validation on all deserialized event payloads; run services in isolated network segments with egress filtering

4. AI Threat Tables

4.1 Agentic Threats (AG)

No agentic components detected in this architecture. The system uses traditional microservice patterns with synchronous REST and asynchronous event-driven communication. No autonomous agents, AI orchestrators, or tool-calling interfaces are present.

ID Component MAESTRO Layer Threat OWASP Reference Likelihood Impact Risk Level Mitigation

Findings: 0

4.2 LLM Threats (LLM)

No LLM components detected in this architecture. The system does not incorporate large language models, prompt-based interfaces, embedding services, or AI-generated content pipelines.

ID Component MAESTRO Layer Threat OWASP Reference Likelihood Impact Risk Level Mitigation

Findings: 0


4a. Correlated Findings

No cross-agent correlations detected.

No AI components are present in this architecture, so no STRIDE-to-AI correlation rules (CR-1 through CR-5) apply.

Group Findings Component Threat Summary Risk Level

5. Coverage Matrix

Component S T R I D E AG LLM Total
Client Application n/a n/a n/a n/a n/a n/a 0
API Gateway 1 1 1 1 n/a n/a 4
Service Registry 1 n/a n/a 1
Order Service 1 1 1 1 1 n/a n/a 5
Payment Service 1 1 1 1 n/a n/a 4
Notification Service 1 1 n/a n/a 2
Message Queue n/a 1 n/a 1 1 n/a n/a n/a 3
Order Database n/a n/a 1 n/a n/a n/a 1
Inventory Database n/a 1 n/a 1 n/a n/a n/a 2
External Payment Provider 1 n/a n/a n/a n/a n/a n/a 1
Total 4 4 3 4 4 4 0 0 23

Cell legend:

  • Integer = number of findings targeting that component in that category
  • (em dash) = analyzed per STRIDE-per-Element rules, no findings identified
  • n/a = not applicable per STRIDE-per-Element rules (External Entities: S, R only; Data Stores: T, I, D only)
  • AG and LLM = n/a for all components (no AI components in this architecture)

6. Risk Summary

OWASP 3x3 risk matrix reference:

LOW Likelihood MEDIUM Likelihood HIGH Likelihood
HIGH Impact Medium High Critical
MEDIUM Impact Low Medium High
LOW Impact Note Low Medium
Risk Level Count Percentage
Critical 3 13.0%
High 11 47.8%
Medium 9 39.1%
Low 0 0.0%
Note 0 0.0%
Total 23 100%

Risk by MAESTRO Layer

MAESTRO Layer Finding Count Highest Severity
L4 — Deployment Infrastructure 14 Critical
L2 — Data Operations 8 Critical
Unclassified 1 Medium

7. Recommended Actions

All findings sorted by risk level descending. Critical and High findings should be addressed before deployment. Medium findings should be addressed within the current development cycle.

Finding ID Status Component Threat Risk Level Mitigation
S-2 NEW Payment Service Service Registry poisoning redirecting payment traffic to attacker-controlled endpoint Critical Service identity verification via mTLS certificates; signed registry entries; health checks verifying service identity; registry change monitoring
D-1 NEW API Gateway Volumetric HTTP flood exhausting connection pool and TLS capacity Critical Upstream DDoS protection; per-IP and per-user rate limiting; connection timeouts; auto-scaling; circuit breaker patterns
D-3 NEW Order Service Cascade failure from Payment Service unavailability exhausting Order Service thread pool Critical Circuit breaker patterns with configurable timeout and failure threshold; bulkhead isolation for payment thread pools; fallback to async payment via Message Queue
S-1 NEW Order Service Rogue internal process impersonating API Gateway to bypass authentication High Enforce mTLS between all internal services; reject requests without valid client certificates; restrict network policies to gateway-only access
S-3 NEW API Gateway JWT token forgery or theft enabling user impersonation High Short-lived JWT (15 min); token revocation lists; issuer/audience validation; asymmetric signing with key rotation
T-1 NEW Message Queue Forged event injection causing false notifications and fabricated payment processing High Message-level HMAC signing; per-queue publish ACLs; network access restrictions to broker port
T-2 NEW Order Service REST payload tampering between API Gateway and Order Service over unencrypted internal HTTP High mTLS for all service-to-service communication; request payload signing; service mesh encryption
T-4 NEW Payment Service Replayed or modified webhook callbacks with altered payment statuses High Webhook signature verification; HTTPS-only endpoints with IP allowlisting; idempotency keys; cross-validation via provider API
R-3 NEW Payment Service Missing end-to-end payment audit trail preventing forensic reconstruction High Correlation IDs linking order ID, MQ message ID, provider charge ID; structured logging with shared trace ID across services
I-1 NEW Order Database Database credentials exposed in error responses propagated to external clients High Generic error codes for upstream callers; internal-only detailed logging; API Gateway stripping internal error details
D-2 NEW Message Queue Event flood consuming broker resources and halting all async processing High Per-queue message limits; publish rate limits; memory/disk watermarks; dead-letter exchanges; queue depth monitoring
D-4 NEW Service Registry Registry flooding causing API Gateway to lose all service endpoints High Authentication and rate limiting on registry APIs; cached last-known-good endpoints; cryptographic auth for registration; replicated cluster deployment
E-2 NEW Order Service Order status manipulation bypassing state machine to fulfill unpaid orders High Strict finite state machine validation; reject invalid transitions; log all state change attempts
E-3 NEW Payment Service Direct internal port access bypassing API Gateway for unauthorized refunds High Network policies restricting port access; service-level mTLS authorization; elevated approval for refund operations
S-4 NEW External Payment Provider DNS hijacking or certificate spoofing intercepting payment requests Medium Certificate pinning; TLS certificate validation; payment reconciliation against provider dashboard; certificate fingerprint change alerts
T-3 NEW Inventory Database Direct stock level manipulation via over-privileged shared database account Medium Least-privilege service accounts; separate read-only reporting accounts; pgaudit logging; alerts on non-application SQL patterns
R-1 NEW Order Service Insufficient audit trail for disputed order placement Medium Append-only audit logging with user ID, session ID, source IP, payload hash, timestamps; tamper-evident storage
R-2 NEW Notification Service Missing notification delivery proof preventing dispute resolution Medium Delivery logging with correlation IDs; integration with provider delivery receipts; retention for compliance period
I-2 NEW Message Queue Sensitive order data readable by any service with valid AMQP credentials Medium Application-layer envelope encryption; per-queue/topic ACLs; dedicated virtual host for payment messages
I-3 NEW Inventory Database Stock and pricing data accessible to all services via shared credentials Medium Per-service database credentials with schema-level access; encrypted sensitive columns; cross-schema query auditing
I-4 NEW API Gateway Verbose error responses exposing internal service topology to external clients Medium Standardized error responses with no internal details; server-side detailed logging; custom error pages hiding backend topology
E-1 NEW API Gateway Undocumented admin routes bypassing JWT validation exposed to external requests Medium Route allowlisting; authentication on all endpoints; regular gateway configuration reviews; automated route scanning in CI/CD
E-4 NEW Notification Service Deserialization exploit pivoting to Message Queue broker credentials Medium Least-privilege MQ credentials (consume-only, no publish); secrets manager for credentials; input validation on deserialized events; network segmentation with egress filtering

Appendix: OWASP Framework Cross-References

Mapping of findings to the OWASP Top 10 Web 2025 framework categories.

Finding ID OWASP Category Category Name Notes
S-1 NEW A07:2025 Authentication Failures
S-2 NEW A07:2025 Authentication Failures
S-3 NEW A07:2025 Authentication Failures
S-4 NEW A04:2025 Cryptographic Failures
T-1 NEW A08:2025 Software or Data Integrity Failures
T-2 NEW A04:2025 Cryptographic Failures
T-3 NEW A01:2025 Broken Access Control
T-4 NEW A08:2025 Software or Data Integrity Failures
R-1 NEW A09:2025 Security Logging and Alerting Failures
R-2 NEW A09:2025 Security Logging and Alerting Failures
R-3 NEW A09:2025 Security Logging and Alerting Failures
I-1 NEW A02:2025 Security Misconfiguration
I-2 NEW A01:2025 Broken Access Control
I-3 NEW A01:2025 Broken Access Control
I-4 NEW A02:2025 Security Misconfiguration
D-1 NEW A10:2025 Mishandling of Exceptional Conditions
D-2 NEW A10:2025 Mishandling of Exceptional Conditions
D-3 NEW A06:2025 Insecure Design
D-4 NEW A02:2025 Security Misconfiguration
E-1 NEW A01:2025 Broken Access Control
E-2 NEW A01:2025 Broken Access Control
E-3 NEW A01:2025 Broken Access Control
E-4 NEW A06:2025 Insecure Design

OWASP Top 10 Web 2025 coverage: 8 of 10 categories referenced.

OWASP Category Category Name Finding Count
A01:2025 Broken Access Control 6
A02:2025 Security Misconfiguration 3
A04:2025 Cryptographic Failures 2
A06:2025 Insecure Design 2
A07:2025 Authentication Failures 3
A08:2025 Software or Data Integrity Failures 2
A09:2025 Security Logging and Alerting Failures 3
A10:2025 Mishandling of Exceptional Conditions 2