A05 — Injection
Injection occurs when untrusted user input is interpreted as part of a command or query by an application.
Common examples include:
SQL Injection
NoSQL Injection
Command Injection
LDAP Injection
Cross-Site Scripting (XSS)
For example, if an application directly includes user input in a database query without proper validation or parameterization, an attacker may manipulate the query's behavior.
User Input
↓
Application
↓
Database / System
↓
Unexpected Behavior
Use parameterized queries, safe APIs, proper input validation, and context-aware output encoding.
Never trust user-controlled input.
A06 — Insecure Design
Insecure Design refers to security weaknesses introduced during the application's design or architecture rather than simply through coding mistakes.
For example, consider a password-reset system that allows unlimited reset attempts without considering rate limiting, abuse prevention, or account takeover scenarios.
The implementation might work exactly as designed—but the design itself is insecure.
Common examples include:
Missing security requirements
Poor authentication design
Lack of rate limiting
Weak authorization models
Missing abuse-case analysis
Inadequate threat modeling
Use threat modeling, secure design principles, security requirements, and architecture reviews early in the development lifecycle.
Security should be designed into an application, not added only after development.
Top comments (0)