Help us improve
Share bugs, ideas, or general feedback.
From python
Provides security architecture guidance and threat modeling using STRIDE. Auto-activates for authentication, authorization, untrusted data, external integrations, and file uploads.
npx claudepluginhub martinffx/atelier --plugin codeHow this skill is triggered — by the user, by Claude, or both
Slash command
/python:oracle-securityThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Auto-invokes when context contains:
Provides OWASP security design principles, STRIDE threat modeling, and architectural mitigations. Use when designing systems or reviewing architecture for security.
Identifies threats and mitigations using STRIDE and trust boundary mapping. Use for systems handling sensitive data, security reviews, or audits.
Design security architecture covering authentication, authorization, data protection, and threat models. Use when building security-critical systems.
Share bugs, ideas, or general feedback.
Auto-invokes when context contains:
Validate at Boundaries — Every entry point is a trust boundary. Assume everything that crosses it is hostile until proven otherwise.
Never Trust the Client — Client-side validation, hidden fields, and browser headers are UX conveniences, not security controls. The server is the only security boundary that matters.
Fail Closed — Deny by default. When in doubt, reject. When validation fails, stop. When auth is uncertain, deny. "Fail open" is an accidental backdoor.
Defense in Depth — No single control should be the only thing preventing compromise. Layer them so that bypassing one still leaves others.
Least Privilege — Every component should have the minimum access necessary to do its job, and only for the minimum time required.
Compartmentalize — A breach in one area should not automatically grant access to everything else. Isolate by function, data sensitivity, and trust level.
External World → [Trust Boundary] → Internal System
↑ ↑
Validate here Enforce here
Sanitize here Audit here
Authenticate here Authorize here
Trust boundaries exist at every system edge where data or control crosses from a less-trusted to a more-trusted zone:
Key insight: Security enforcement should happen as close to the trust boundary as possible. Don't let untrusted data travel deep into your system before validation.
For every feature, ask these six questions:
| Threat | Question | Example Concern |
|---|---|---|
| Spoofing | Who could pretend to be someone else? | Fake user IDs, stolen tokens, forged requests |
| Tampering | What could be modified in transit or at rest? | Request payload alteration, data corruption |
| Repudiation | Can actions be denied after the fact? | Missing audit logs, unaccountable changes |
| Information Disclosure | What sensitive data could leak? | Error messages, logs, API responses |
| Denial of Service | How could this be overwhelmed or broken? | No rate limits, expensive queries, resource exhaustion |
| Elevation of Privilege | Who could gain more access than intended? | Missing authorization checks, parameter tampering |
For critical features, build a simple attack tree:
Usage: You don't need a formal diagram. A bullet list of "to steal X, attacker could Y which is blocked by Z, unless they find W" is sufficient for most design reviews.
Consider two factors:
| Context | Typical Posture |
|---|---|
| Public-facing, unauthenticated | Maximum validation, rate limiting, minimal data exposure, aggressive fail-closed |
| Authenticated user operations | Standard validation, authorization checks, audit logging, session management |
| Internal admin tools | Authentication essential, authorization by role, audit everything, additional monitoring |
| Background processing | Input validation still required, fail-safe defaults, logging for debugging |
Adjust based on your threat model. A public search box and an internal admin panel have different risks. Don't apply maximum security everywhere — apply proportional security everywhere.
Don't rely on a single control. Layer them:
Input → [Validation] → [Authentication] → [Authorization] → [Audit]
↑ ↑ ↑ ↑
Reject bad Verify who Check can-do Log did-do
data they are they have they did
If any layer fails, the others still provide protection. A validation bypass shouldn't automatically mean unauthorized access.
Corollary: When a component needs elevated access temporarily, that access should be explicitly granted and automatically revoked.
Key question: "If this component fails or is misconfigured, what's the safest default state?"
Ask before implementing:
Trusting external input without validation — Browser headers, webhook payloads, file contents, third-party API responses. All are untrusted until validated.
Single authorization check at entry — Checking auth at the route level but not verifying resource ownership on each operation. Every action on a resource needs its own authorization check.
Errors revealing system internals — Stack traces, database schemas, file paths, internal IDs in error messages. Debug information belongs in logs, not responses.
No audit trail for sensitive operations — If you can't reconstruct who did what after an incident, you can't investigate or recover.
Broad permissions by default — Service accounts with admin access, tokens with blanket permissions, users with more roles than they need.
Security logic in client code — "The frontend will validate" or "the mobile app won't send that." The client is not a security boundary.
| Rationalization | Reality |
|---|---|
| "It's just a prototype" | Prototypes become production. Security habits from day one prevent day-one-hundred emergencies. |
| "This is an internal tool" | Internal tools are targets. Attackers look for the weakest link, and internal systems are often it. |
| "We'll add security later" | Later rarely comes. Retrofitting is expensive, error-prone, and usually incomplete. |
| "The framework handles security" | Frameworks provide primitives. You compose them correctly. They don't secure your application by default. |
| "No one would target us" | Automated attacks are indiscriminate. Scanners don't care who you are. |
| "Security slows development" | Insecure code costs more: incident response, legal exposure, user trust loss. |
After designing security-relevant features:
references/threat-modeling-guide.md — Extended threat modeling approachesreferences/security-patterns.md — Catalog of security design patternsSecurity is not a feature you add. It's a property of the system you design.