ShopFast — Online Retail Platform

📍Where the threat exists

Within component API Gateway (api).

📝Description

Attackers reuse leaked credentials to impersonate legitimate users.

⚔️Attack scenario

1. Attacker locates API Gateway's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. API Gateway accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

Attacker steals or predicts a session token to impersonate a user.

⚔️Attack scenario

1. Attacker locates API Gateway's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. API Gateway accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

An attacker obtains or forges an API key to act as a trusted service.

⚔️Attack scenario

1. Attacker locates API Gateway's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. API Gateway accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

An attacker with access modifies or deletes audit trails.

⚔️Attack scenario

1. User performs a sensitive action through API Gateway (a transfer, a permission change, a deletion).
2. Audit logs are absent, incomplete, or modifiable by the same principal who performed the action.
3. User later denies having performed the action, or an attacker covers their tracks.
4. Without tamper-evident logs, neither responsible party can be identified — leading to fraud, dispute, or regulatory exposure.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

PII, secrets, or tokens transmitted over unencrypted channels.

⚔️Attack scenario

1. Attacker reaches API Gateway via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

Stored PII / secrets accessible without proper authorization.

⚔️Attack scenario

1. Attacker reaches API Gateway via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

User can access another user's resources by guessing IDs.

⚔️Attack scenario

1. Attacker reaches API Gateway via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

Attacker floods expensive endpoints (e.g., search, login).

⚔️Attack scenario

1. Attacker identifies a costly operation in API Gateway (regex matching, file generation, expensive query, large allocation).
2. Issues many concurrent requests targeting that operation, or a single request with pathological input.
3. API Gateway's resources (CPU, memory, connections, disk) saturate or exhaust.
4. Legitimate users can no longer reach API Gateway; cascading failure may take down dependents.

🛡How to mitigate

📍Where the threat exists

Within component API Gateway (api).

📝Description

User submits extra fields (e.g., role=admin) and they bind to the model.

⚔️Attack scenario

1. Attacker authenticates to API Gateway as a low-privilege user, or reaches an unauthenticated entry point.
2. Identifies an authorization gap — a function that doesn't re-check the caller's role, an IDOR-style URL, an admin endpoint with weak gating.
3. Issues requests to that gap, gaining access to data or actions reserved for higher-privilege roles.
4. Now operating with elevated privilege, attacker can pivot to other components, exfiltrate data, or persist access.

🛡How to mitigate

📍Where the threat exists

On the data flow Mobile App → API Gateway (label: *—*, protocol: HTTPS, auth: none, encrypted: yes). The receiving component is API Gateway (api).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at API Gateway (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. API Gateway processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow Web Frontend → API Gateway (label: *—*, protocol: HTTPS, auth: none, encrypted: yes). The receiving component is API Gateway (api).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at API Gateway (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. API Gateway processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow Admin Portal → API Gateway (label: *—*, protocol: HTTPS, auth: none, encrypted: yes). The receiving component is API Gateway (api).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at API Gateway (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. API Gateway processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow Mobile App → API Gateway (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from Internet into DMZ (public-facing). The receiving component is API Gateway (api).

📝Description

Flow '' crosses trust boundary 'Internet' → 'DMZ (public-facing)'. Caller identity must be re-verified at the boundary; existing trust does not transit.

⚔️Attack scenario

1. Attacker positions themselves on the network path between source and destination, or compromises an upstream component in the source zone.
2. Crafts requests with forged or replayed identity claims (cookies, tokens, IP-based trust).
3. API Gateway accepts the request because identity is not re-verified at the boundary, treating the upstream zone as trusted.
4. Attacker can now perform actions as the impersonated principal across the boundary.

🛡How to mitigate

📍Where the threat exists

On the data flow Mobile App → API Gateway (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from Internet into DMZ (public-facing). The receiving component is API Gateway (api).

📝Description

Data crossing the trust boundary into 'DMZ (public-facing)' must be treated as untrusted, even if the source is internal. Implicit trust is the most common cause of injection / SSRF / deserialization bugs.

⚔️Attack scenario

1. Attacker compromises a less-trusted upstream zone or directly sends malformed input to API Gateway.
2. Sends payloads with unexpected types, lengths, or special characters (e.g. SQL meta-chars, NUL bytes, control sequences).
3. API Gateway processes the input under the assumption that the upstream zone has already validated it — but the boundary changes the security context.
4. Injection, deserialization flaws, or buffer issues trigger; attacker pivots into API Gateway or the zone behind it.

🛡How to mitigate

📍Where the threat exists

On the data flow Mobile App → API Gateway (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from Internet into DMZ (public-facing). The receiving component is API Gateway (api).

📝Description

Information leaving 'Internet' into 'DMZ (public-facing)' may include data the receiving zone is not authorized to see. Cross-boundary egress is a common data-leak surface.

⚔️Attack scenario

1. Attacker observes traffic leaving the source zone, or compromises a component in the destination zone.
2. The destination zone receives more data than it strictly needs (over-fetching, verbose error responses, full record dumps).
3. Attacker harvests sensitive fields (PII, secrets, internal IDs) that should never have left the source zone.
4. Data is exfiltrated, sold, or used to plan a deeper attack on the originating zone.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

Attackers reuse leaked credentials to impersonate legitimate users.

⚔️Attack scenario

1. Attacker locates Admin Portal's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. Admin Portal accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

Attacker steals or predicts a session token to impersonate a user.

⚔️Attack scenario

1. Attacker locates Admin Portal's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. Admin Portal accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

An attacker obtains or forges an API key to act as a trusted service.

⚔️Attack scenario

1. Attacker locates Admin Portal's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. Admin Portal accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

An attacker with access modifies or deletes audit trails.

⚔️Attack scenario

1. User performs a sensitive action through Admin Portal (a transfer, a permission change, a deletion).
2. Audit logs are absent, incomplete, or modifiable by the same principal who performed the action.
3. User later denies having performed the action, or an attacker covers their tracks.
4. Without tamper-evident logs, neither responsible party can be identified — leading to fraud, dispute, or regulatory exposure.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

PII, secrets, or tokens transmitted over unencrypted channels.

⚔️Attack scenario

1. Attacker reaches Admin Portal via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

Stored PII / secrets accessible without proper authorization.

⚔️Attack scenario

1. Attacker reaches Admin Portal via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

User can access another user's resources by guessing IDs.

⚔️Attack scenario

1. Attacker reaches Admin Portal via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

Attacker floods expensive endpoints (e.g., search, login).

⚔️Attack scenario

1. Attacker identifies a costly operation in Admin Portal (regex matching, file generation, expensive query, large allocation).
2. Issues many concurrent requests targeting that operation, or a single request with pathological input.
3. Admin Portal's resources (CPU, memory, connections, disk) saturate or exhaust.
4. Legitimate users can no longer reach Admin Portal; cascading failure may take down dependents.

🛡How to mitigate

📍Where the threat exists

Within component Admin Portal (webapp).

📝Description

User submits extra fields (e.g., role=admin) and they bind to the model.

⚔️Attack scenario

1. Attacker authenticates to Admin Portal as a low-privilege user, or reaches an unauthenticated entry point.
2. Identifies an authorization gap — a function that doesn't re-check the caller's role, an IDOR-style URL, an admin endpoint with weak gating.
3. Issues requests to that gap, gaining access to data or actions reserved for higher-privilege roles.
4. Now operating with elevated privilege, attacker can pivot to other components, exfiltrate data, or persist access.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Auth Service (label: *—*, protocol: HTTPS, auth: none, encrypted: yes). The receiving component is Auth Service (service).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at Auth Service (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. Auth Service processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Auth Service (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from DMZ (public-facing) into Application tier. The receiving component is Auth Service (service).

📝Description

Flow '' crosses trust boundary 'DMZ (public-facing)' → 'Application tier'. Caller identity must be re-verified at the boundary; existing trust does not transit.

⚔️Attack scenario

1. Attacker positions themselves on the network path between source and destination, or compromises an upstream component in the source zone.
2. Crafts requests with forged or replayed identity claims (cookies, tokens, IP-based trust).
3. Auth Service accepts the request because identity is not re-verified at the boundary, treating the upstream zone as trusted.
4. Attacker can now perform actions as the impersonated principal across the boundary.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Auth Service (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from DMZ (public-facing) into Application tier. The receiving component is Auth Service (service).

📝Description

Data crossing the trust boundary into 'Application tier' must be treated as untrusted, even if the source is internal. Implicit trust is the most common cause of injection / SSRF / deserialization bugs.

⚔️Attack scenario

1. Attacker compromises a less-trusted upstream zone or directly sends malformed input to Auth Service.
2. Sends payloads with unexpected types, lengths, or special characters (e.g. SQL meta-chars, NUL bytes, control sequences).
3. Auth Service processes the input under the assumption that the upstream zone has already validated it — but the boundary changes the security context.
4. Injection, deserialization flaws, or buffer issues trigger; attacker pivots into Auth Service or the zone behind it.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Auth Service (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from DMZ (public-facing) into Application tier. The receiving component is Auth Service (service).

📝Description

Information leaving 'DMZ (public-facing)' into 'Application tier' may include data the receiving zone is not authorized to see. Cross-boundary egress is a common data-leak surface.

⚔️Attack scenario

1. Attacker observes traffic leaving the source zone, or compromises a component in the destination zone.
2. The destination zone receives more data than it strictly needs (over-fetching, verbose error responses, full record dumps).
3. Attacker harvests sensitive fields (PII, secrets, internal IDs) that should never have left the source zone.
4. Data is exfiltrated, sold, or used to plan a deeper attack on the originating zone.

🛡How to mitigate

📍Where the threat exists

Within component Customer Browser (user).

📝Description

Attackers reuse leaked credentials to impersonate legitimate users.

⚔️Attack scenario

1. Attacker obtains valid credentials via phishing, credential stuffing, or a third-party breach.
2. Logs in as the legitimate user/entity at Customer Browser.
3. Performs actions indistinguishable from the real user (auth events look normal).
4. Damage scales with the impersonated user's permissions; admin accounts cause the most harm.

🛡How to mitigate

📍Where the threat exists

Within component Customer Browser (user).

📝Description

Attacker steals or predicts a session token to impersonate a user.

⚔️Attack scenario

1. Attacker obtains valid credentials via phishing, credential stuffing, or a third-party breach.
2. Logs in as the legitimate user/entity at Customer Browser.
3. Performs actions indistinguishable from the real user (auth events look normal).
4. Damage scales with the impersonated user's permissions; admin accounts cause the most harm.

🛡How to mitigate

📍Where the threat exists

Within component Customer Browser (user).

📝Description

An attacker obtains or forges an API key to act as a trusted service.

⚔️Attack scenario

1. Attacker obtains valid credentials via phishing, credential stuffing, or a third-party breach.
2. Logs in as the legitimate user/entity at Customer Browser.
3. Performs actions indistinguishable from the real user (auth events look normal).
4. Damage scales with the impersonated user's permissions; admin accounts cause the most harm.

🛡How to mitigate

📍Where the threat exists

Within component Mobile App (user).

📝Description

Attackers reuse leaked credentials to impersonate legitimate users.

⚔️Attack scenario

1. Attacker obtains valid credentials via phishing, credential stuffing, or a third-party breach.
2. Logs in as the legitimate user/entity at Mobile App.
3. Performs actions indistinguishable from the real user (auth events look normal).
4. Damage scales with the impersonated user's permissions; admin accounts cause the most harm.

🛡How to mitigate

📍Where the threat exists

Within component Mobile App (user).

📝Description

Attacker steals or predicts a session token to impersonate a user.

⚔️Attack scenario

1. Attacker obtains valid credentials via phishing, credential stuffing, or a third-party breach.
2. Logs in as the legitimate user/entity at Mobile App.
3. Performs actions indistinguishable from the real user (auth events look normal).
4. Damage scales with the impersonated user's permissions; admin accounts cause the most harm.

🛡How to mitigate

📍Where the threat exists

Within component Mobile App (user).

📝Description

An attacker obtains or forges an API key to act as a trusted service.

⚔️Attack scenario

1. Attacker obtains valid credentials via phishing, credential stuffing, or a third-party breach.
2. Logs in as the legitimate user/entity at Mobile App.
3. Performs actions indistinguishable from the real user (auth events look normal).
4. Damage scales with the impersonated user's permissions; admin accounts cause the most harm.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

Attacker on the network path alters request/response payloads.

⚔️Attack scenario

1. Attacker reaches an input vector exposed by Orders DB (Postgres) (request body, query string, message queue payload, persisted state).
2. Submits malformed input designed to alter the program's logic or stored data (injection, parameter tampering, deserialization gadgets).
3. Orders DB (Postgres) processes the input without strict validation, and the malicious change takes effect.
4. Tampered data is persisted, executed, or relayed downstream — corrupting integrity beyond the original entry point.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

Unauthorized changes to runtime config alter security behavior.

⚔️Attack scenario

1. Attacker reaches an input vector exposed by Orders DB (Postgres) (request body, query string, message queue payload, persisted state).
2. Submits malformed input designed to alter the program's logic or stored data (injection, parameter tampering, deserialization gadgets).
3. Orders DB (Postgres) processes the input without strict validation, and the malicious change takes effect.
4. Tampered data is persisted, executed, or relayed downstream — corrupting integrity beyond the original entry point.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

An attacker with access modifies or deletes audit trails.

⚔️Attack scenario

1. User performs a sensitive action through Orders DB (Postgres) (a transfer, a permission change, a deletion).
2. Audit logs are absent, incomplete, or modifiable by the same principal who performed the action.
3. User later denies having performed the action, or an attacker covers their tracks.
4. Without tamper-evident logs, neither responsible party can be identified — leading to fraud, dispute, or regulatory exposure.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

PII, secrets, or tokens transmitted over unencrypted channels.

⚔️Attack scenario

1. Attacker reaches Orders DB (Postgres) via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

Stored PII / secrets accessible without proper authorization.

⚔️Attack scenario

1. Attacker reaches Orders DB (Postgres) via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

User can access another user's resources by guessing IDs.

⚔️Attack scenario

1. Attacker reaches Orders DB (Postgres) via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

Attacker floods expensive endpoints (e.g., search, login).

⚔️Attack scenario

1. Attacker identifies a costly operation in Orders DB (Postgres) (regex matching, file generation, expensive query, large allocation).
2. Issues many concurrent requests targeting that operation, or a single request with pathological input.
3. Orders DB (Postgres)'s resources (CPU, memory, connections, disk) saturate or exhaust.
4. Legitimate users can no longer reach Orders DB (Postgres); cascading failure may take down dependents.

🛡How to mitigate

📍Where the threat exists

Within component Orders DB (Postgres) (database).

📝Description

User submits extra fields (e.g., role=admin) and they bind to the model.

⚔️Attack scenario

1. Attacker authenticates to Orders DB (Postgres) as a low-privilege user, or reaches an unauthenticated entry point.
2. Identifies an authorization gap — a function that doesn't re-check the caller's role, an IDOR-style URL, an admin endpoint with weak gating.
3. Issues requests to that gap, gaining access to data or actions reserved for higher-privilege roles.
4. Now operating with elevated privilege, attacker can pivot to other components, exfiltrate data, or persist access.

🛡How to mitigate

📍Where the threat exists

On the data flow Orders Service → Orders DB (Postgres) (label: *—*, protocol: TCP, auth: none, encrypted: no). The receiving component is Orders DB (Postgres) (database).

📝Description

Data flow '' uses TCP without encryption.

⚔️Attack scenario

1. Attacker gains read access to the network path (sniffing on shared LAN, compromised router, hostile cloud tenant, malicious admin).
2. Captures cleartext traffic on the TCP channel.
3. Extracts credentials, session tokens, PII, or business secrets from packet captures.
4. Uses the credentials to impersonate Orders DB (Postgres) or the calling component, or sells/leaks the captured data.

🛡How to mitigate

📍Where the threat exists

On the data flow Orders Service → Orders DB (Postgres) (label: *—*, protocol: TCP, auth: none, encrypted: no). The receiving component is Orders DB (Postgres) (database).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at Orders DB (Postgres) (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. Orders DB (Postgres) processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow Orders Service → Orders DB (Postgres) (label: *—*, protocol: TCP, auth: none, encrypted: no), crossing the trust boundary from Application tier into Data tier. The receiving component is Orders DB (Postgres) (database).

📝Description

Flow '' crosses trust boundary 'Application tier' → 'Data tier'. Caller identity must be re-verified at the boundary; existing trust does not transit.

⚔️Attack scenario

1. Attacker positions themselves on the network path between source and destination, or compromises an upstream component in the source zone.
2. Crafts requests with forged or replayed identity claims (cookies, tokens, IP-based trust).
3. Orders DB (Postgres) accepts the request because identity is not re-verified at the boundary, treating the upstream zone as trusted.
4. Attacker can now perform actions as the impersonated principal across the boundary.

🛡How to mitigate

📍Where the threat exists

On the data flow Orders Service → Orders DB (Postgres) (label: *—*, protocol: TCP, auth: none, encrypted: no), crossing the trust boundary from Application tier into Data tier. The receiving component is Orders DB (Postgres) (database).

📝Description

Data crossing the trust boundary into 'Data tier' must be treated as untrusted, even if the source is internal. Implicit trust is the most common cause of injection / SSRF / deserialization bugs.

⚔️Attack scenario

1. Attacker compromises a less-trusted upstream zone or directly sends malformed input to Orders DB (Postgres).
2. Sends payloads with unexpected types, lengths, or special characters (e.g. SQL meta-chars, NUL bytes, control sequences).
3. Orders DB (Postgres) processes the input under the assumption that the upstream zone has already validated it — but the boundary changes the security context.
4. Injection, deserialization flaws, or buffer issues trigger; attacker pivots into Orders DB (Postgres) or the zone behind it.

🛡How to mitigate

📍Where the threat exists

On the data flow Orders Service → Orders DB (Postgres) (label: *—*, protocol: TCP, auth: none, encrypted: no), crossing the trust boundary from Application tier into Data tier. The receiving component is Orders DB (Postgres) (database).

📝Description

Information leaving 'Application tier' into 'Data tier' may include data the receiving zone is not authorized to see. Cross-boundary egress is a common data-leak surface.

⚔️Attack scenario

1. Attacker observes traffic leaving the source zone, or compromises a component in the destination zone.
2. The destination zone receives more data than it strictly needs (over-fetching, verbose error responses, full record dumps).
3. Attacker harvests sensitive fields (PII, secrets, internal IDs) that should never have left the source zone.
4. Data is exfiltrated, sold, or used to plan a deeper attack on the originating zone.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Orders Service (label: *—*, protocol: HTTP, auth: none, encrypted: no). The receiving component is Orders Service (service).

📝Description

Data flow '' uses HTTP without encryption.

⚔️Attack scenario

1. Attacker gains read access to the network path (sniffing on shared LAN, compromised router, hostile cloud tenant, malicious admin).
2. Captures cleartext traffic on the HTTP channel.
3. Extracts credentials, session tokens, PII, or business secrets from packet captures.
4. Uses the credentials to impersonate Orders Service or the calling component, or sells/leaks the captured data.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Orders Service (label: *—*, protocol: HTTP, auth: none, encrypted: no). The receiving component is Orders Service (service).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at Orders Service (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. Orders Service processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Orders Service (label: *—*, protocol: HTTP, auth: none, encrypted: no), crossing the trust boundary from DMZ (public-facing) into Application tier. The receiving component is Orders Service (service).

📝Description

Flow '' crosses trust boundary 'DMZ (public-facing)' → 'Application tier'. Caller identity must be re-verified at the boundary; existing trust does not transit.

⚔️Attack scenario

1. Attacker positions themselves on the network path between source and destination, or compromises an upstream component in the source zone.
2. Crafts requests with forged or replayed identity claims (cookies, tokens, IP-based trust).
3. Orders Service accepts the request because identity is not re-verified at the boundary, treating the upstream zone as trusted.
4. Attacker can now perform actions as the impersonated principal across the boundary.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Orders Service (label: *—*, protocol: HTTP, auth: none, encrypted: no), crossing the trust boundary from DMZ (public-facing) into Application tier. The receiving component is Orders Service (service).

📝Description

Data crossing the trust boundary into 'Application tier' must be treated as untrusted, even if the source is internal. Implicit trust is the most common cause of injection / SSRF / deserialization bugs.

⚔️Attack scenario

1. Attacker compromises a less-trusted upstream zone or directly sends malformed input to Orders Service.
2. Sends payloads with unexpected types, lengths, or special characters (e.g. SQL meta-chars, NUL bytes, control sequences).
3. Orders Service processes the input under the assumption that the upstream zone has already validated it — but the boundary changes the security context.
4. Injection, deserialization flaws, or buffer issues trigger; attacker pivots into Orders Service or the zone behind it.

🛡How to mitigate

📍Where the threat exists

On the data flow API Gateway → Orders Service (label: *—*, protocol: HTTP, auth: none, encrypted: no), crossing the trust boundary from DMZ (public-facing) into Application tier. The receiving component is Orders Service (service).

📝Description

Information leaving 'DMZ (public-facing)' into 'Application tier' may include data the receiving zone is not authorized to see. Cross-boundary egress is a common data-leak surface.

⚔️Attack scenario

1. Attacker observes traffic leaving the source zone, or compromises a component in the destination zone.
2. The destination zone receives more data than it strictly needs (over-fetching, verbose error responses, full record dumps).
3. Attacker harvests sensitive fields (PII, secrets, internal IDs) that should never have left the source zone.
4. Data is exfiltrated, sold, or used to plan a deeper attack on the originating zone.

🛡How to mitigate

📍Where the threat exists

On the data flow Orders Service → Payment Provider (label: *—*, protocol: HTTPS, auth: none, encrypted: yes). The receiving component is Payment Provider (external).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at Payment Provider (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. Payment Provider processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

Attackers reuse leaked credentials to impersonate legitimate users.

⚔️Attack scenario

1. Attacker locates Web Frontend's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. Web Frontend accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

Attacker steals or predicts a session token to impersonate a user.

⚔️Attack scenario

1. Attacker locates Web Frontend's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. Web Frontend accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

An attacker obtains or forges an API key to act as a trusted service.

⚔️Attack scenario

1. Attacker locates Web Frontend's identity claim mechanism (token format, header name, signing key handling).
2. Forges or replays a token to assert another principal's identity.
3. Web Frontend accepts the claim because verification is missing or weak (e.g., signature not checked, expired tokens accepted, no audience validation).
4. Attacker acts as the spoofed principal — reading data, triggering workflows, or pivoting to internal services.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

An attacker with access modifies or deletes audit trails.

⚔️Attack scenario

1. User performs a sensitive action through Web Frontend (a transfer, a permission change, a deletion).
2. Audit logs are absent, incomplete, or modifiable by the same principal who performed the action.
3. User later denies having performed the action, or an attacker covers their tracks.
4. Without tamper-evident logs, neither responsible party can be identified — leading to fraud, dispute, or regulatory exposure.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

PII, secrets, or tokens transmitted over unencrypted channels.

⚔️Attack scenario

1. Attacker reaches Web Frontend via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

Stored PII / secrets accessible without proper authorization.

⚔️Attack scenario

1. Attacker reaches Web Frontend via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

User can access another user's resources by guessing IDs.

⚔️Attack scenario

1. Attacker reaches Web Frontend via a legitimate or guessable channel.
2. Triggers an error, edge case, or verbose endpoint that returns more information than necessary (stack traces, internal IDs, debug data, full PII fields).
3. Aggregates leaked information from multiple requests to build a profile of the system or its users.
4. Uses the harvested information to plan a targeted attack, reset accounts, or commit fraud.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

Attacker floods expensive endpoints (e.g., search, login).

⚔️Attack scenario

1. Attacker identifies a costly operation in Web Frontend (regex matching, file generation, expensive query, large allocation).
2. Issues many concurrent requests targeting that operation, or a single request with pathological input.
3. Web Frontend's resources (CPU, memory, connections, disk) saturate or exhaust.
4. Legitimate users can no longer reach Web Frontend; cascading failure may take down dependents.

🛡How to mitigate

📍Where the threat exists

Within component Web Frontend (webapp).

📝Description

User submits extra fields (e.g., role=admin) and they bind to the model.

⚔️Attack scenario

1. Attacker authenticates to Web Frontend as a low-privilege user, or reaches an unauthenticated entry point.
2. Identifies an authorization gap — a function that doesn't re-check the caller's role, an IDOR-style URL, an admin endpoint with weak gating.
3. Issues requests to that gap, gaining access to data or actions reserved for higher-privilege roles.
4. Now operating with elevated privilege, attacker can pivot to other components, exfiltrate data, or persist access.

🛡How to mitigate

📍Where the threat exists

On the data flow Customer Browser → Web Frontend (label: *—*, protocol: HTTPS, auth: none, encrypted: yes). The receiving component is Web Frontend (webapp).

📝Description

Data flow has no authentication mechanism declared.

⚔️Attack scenario

1. Attacker discovers the endpoint at Web Frontend (port scan, leaked config, error messages, or DNS enumeration).
2. Sends requests directly without any credentials, since the flow does not require authentication.
3. Web Frontend processes the request as if it came from a trusted caller and returns data or executes the action.
4. Attacker enumerates data, modifies records, or chains to other internal services from this entry point.

🛡How to mitigate

📍Where the threat exists

On the data flow Customer Browser → Web Frontend (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from Internet into DMZ (public-facing). The receiving component is Web Frontend (webapp).

📝Description

Flow '' crosses trust boundary 'Internet' → 'DMZ (public-facing)'. Caller identity must be re-verified at the boundary; existing trust does not transit.

⚔️Attack scenario

1. Attacker positions themselves on the network path between source and destination, or compromises an upstream component in the source zone.
2. Crafts requests with forged or replayed identity claims (cookies, tokens, IP-based trust).
3. Web Frontend accepts the request because identity is not re-verified at the boundary, treating the upstream zone as trusted.
4. Attacker can now perform actions as the impersonated principal across the boundary.

🛡How to mitigate

📍Where the threat exists

On the data flow Customer Browser → Web Frontend (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from Internet into DMZ (public-facing). The receiving component is Web Frontend (webapp).

📝Description

Data crossing the trust boundary into 'DMZ (public-facing)' must be treated as untrusted, even if the source is internal. Implicit trust is the most common cause of injection / SSRF / deserialization bugs.

⚔️Attack scenario

1. Attacker compromises a less-trusted upstream zone or directly sends malformed input to Web Frontend.
2. Sends payloads with unexpected types, lengths, or special characters (e.g. SQL meta-chars, NUL bytes, control sequences).
3. Web Frontend processes the input under the assumption that the upstream zone has already validated it — but the boundary changes the security context.
4. Injection, deserialization flaws, or buffer issues trigger; attacker pivots into Web Frontend or the zone behind it.

🛡How to mitigate

📍Where the threat exists

On the data flow Customer Browser → Web Frontend (label: *—*, protocol: HTTPS, auth: none, encrypted: yes), crossing the trust boundary from Internet into DMZ (public-facing). The receiving component is Web Frontend (webapp).

📝Description

Information leaving 'Internet' into 'DMZ (public-facing)' may include data the receiving zone is not authorized to see. Cross-boundary egress is a common data-leak surface.

⚔️Attack scenario

1. Attacker observes traffic leaving the source zone, or compromises a component in the destination zone.
2. The destination zone receives more data than it strictly needs (over-fetching, verbose error responses, full record dumps).
3. Attacker harvests sensitive fields (PII, secrets, internal IDs) that should never have left the source zone.
4. Data is exfiltrated, sold, or used to plan a deeper attack on the originating zone.

🛡How to mitigate