A04 Insecure Design

What this means

SiteShadow flagged patterns that suggest the system's *design* relies on "hope" rather than explicit controls (missing abuse cases, missing guardrails, trusting the client, or having no clear security boundaries).

Why it matters

Insecure design choices can create systemic weaknesses that are hard to fix later.

• Bugs become exploits because there's no backstop (rate limits, authorization checks, input constraints).
• Business logic gets abused even when the code is "correct."
• Costs more later: fixing design flaws usually means changing APIs/data models, not a single line.

Safer examples

1) Define abuse cases early (and implement guardrails)

• "What if someone runs this 10,000 times?"
• "What if a user modifies IDs in URLs?"
• "What if input is huge or malformed?"

2) Keep trust boundaries server-side

• Treat the client as untrusted.
• Enforce authorization, pricing, and state transitions on the server.

3) Add defense-in-depth primitives

• Rate limits, quotas, and circuit breakers
• Centralized auth middleware/policies
• Input validation + output encoding

How SiteShadow detects it (high level)

• Looks for "control gaps" around sensitive operations (missing limits, missing authorization, client-trusted fields).
• Flags repeated patterns that indicate systemic risk (e.g., many endpoints binding directly to models, many "skip checks" toggles).

References

• OWASP Top 10: https://owasp.org/Top10/

---

← Back to Vulnerability Library