Insecure Design Skill

Insecure design means the vulnerability is in the architecture, not the implementation. No amount of code review catches a design that allows users to reset other users' passwords, a multi-tenant system that shares data incorrectly, or an API that exposes bulk export without rate limiting. These are design decisions. They need to be examined before code is written.

Required Before Starting Implementation

For any new feature in scope (auth flows, payment handling, admin functions, data export, multi-tenant boundaries, bulk operations), produce a threat model with these four questions answered:

1. What is the trust boundary? Where does authenticated context begin and end? What does the system trust that it should not? Who can call this endpoint or function, and what can they do?

2. What is the worst-case abuse scenario? If an attacker has a valid account, what is the most damaging thing they can do with this feature? If the system has no rate limit, what happens when someone calls this endpoint 10,000 times? If an ID is sequential, what happens when someone increments it?

3. What data is handled and where does it go? Map the data: user input arrives, what gets persisted, what gets returned, what gets logged, what gets sent to a third party. Any step where sensitive data is broader than necessary is a design flaw.

4. Is there a rate limit, retry limit, or volume constraint? Bulk operations, password resets, login attempts, and API calls without limits are design vulnerabilities. State the limit or explain why one is not required.