soden46 Security
Use this skill when a task creates, changes, reviews, or fixes a security-sensitive application boundary.
The rules in this skill are framework and language agnostic.
Do not assume a specific framework, ORM, authentication library, HTTP server, database, queue, cloud provider, or deployment platform.
Core Principle
Identify the security boundary first.
Then use the safest native mechanism available in the detected project stack.
Technology-specific implementation details should be derived from project evidence, native stack mechanisms, or relevant user-installed specialist skills rather than hardcoded into this skill.
Security Review Scope
Check only areas relevant to the change.
Primary areas:
- authentication
- authorization
- input validation
- output encoding
- request forgery protection
- injection
- secret handling
- sensitive data exposure
- file uploads
- API security
- rate limiting and abuse protection
- session and token handling
- dependency and configuration security
- logging and error disclosure
- unsafe redirects and outbound requests
- serialization and deserialization
- access to filesystem, network, subprocesses, and other privileged resources
Do not mechanically run every category for every task.
1. Trust Boundaries
Treat data crossing a trust boundary as untrusted until validated.
Common boundaries include:
- HTTP requests
- API payloads
- form input
- URL parameters
- headers
- cookies
- uploaded files
- webhooks
- message queues
- database content originating from users
- external APIs
- environment/configuration values
- files
- command-line arguments
Validate as close to the boundary as practical.
Validation should constrain:
- type
- structure
- allowed values
- length
- range
- format
- relationships between fields
Prefer allowlists and explicit schemas over ad-hoc filtering.
Do not rely on frontend validation for server-side security.
2. Authentication
Use established authentication mechanisms provided by the project stack.
Do not implement custom password hashing, token signing, session cryptography, or authentication protocols when a trusted implementation exists.
Verify:
- credentials are handled securely
- authentication state cannot be forged
- password storage uses an appropriate adaptive password hash
- session or token rotation is handled where required
- logout/revocation behavior is correct
- authentication failures do not leak unnecessary information
Authentication answers:
"Who is this actor?"
It does not answer:
"May this actor perform this operation?"
3. Authorization
Perform authorization on the server side for every protected operation.
Authorize the requested action against the actual target resource.
Check authorization before performing sensitive state changes.
Protect against:
- insecure direct object references
- horizontal privilege escalation
- vertical privilege escalation
- tenant boundary bypass
- ownership bypass
- administrator-only operation exposure
Prefer centralized authorization mechanisms provided by the project stack.
Do not spread inconsistent role checks throughout business code when a policy/permission mechanism exists.
4. Injection
Never construct executable commands or queries by concatenating untrusted input.
Use appropriate parameterization or structured APIs for:
- database queries
- shell commands
- templates
- directory/LDAP queries
- search expressions
- dynamic code execution
Avoid evaluating user-controlled code or expressions.
Treat escaping as context-specific.
Escaping for HTML is not equivalent to escaping for SQL, shell, JavaScript, URLs, or another interpreter.
5. Output Encoding
Encode or escape untrusted data for the destination context.
Pay special attention to:
- HTML
- HTML attributes
- JavaScript
- URLs
- CSS
- templates
- generated documents
Prefer rendering systems that escape output by default.
Avoid disabling automatic escaping unless the value is known to be safe for that exact output context.
6. Request Forgery
For state-changing browser requests authenticated by ambient credentials such as cookies, use the framework/platform's request-forgery protection.
Do not disable protection globally to fix an integration problem.
For machine-to-machine callbacks or webhooks, use an authentication mechanism appropriate to that boundary, such as:
- signed requests
- authenticated tokens
- mutual authentication
- provider verification mechanisms
Do not confuse webhook signature verification with browser CSRF protection.
7. Rate Limiting and Abuse Protection
Apply rate limits where abuse can cause meaningful harm.
Examples:
- login attempts
- password reset
- verification codes
- expensive searches
- public APIs
- file processing
- resource creation
- messaging endpoints
- authentication/token endpoints
Choose limits based on risk and expected traffic.
Avoid using one global limit for unrelated workloads.
Rate limiting is not a replacement for authorization or validation.
8. File Uploads
Treat uploaded files as hostile.
Validate:
- size
- expected media/type
- extension when relevant
- actual content when relevant
- filename handling
- storage location
- access permissions
Generate server-controlled storage names where possible.
Do not trust the client-provided filename or content type.
Prevent path traversal.
Avoid storing executable uploads in locations where the application server can execute them.
Keep public/private storage semantics explicit.
9. Secrets
Never hardcode production secrets in source code.
Do not expose secrets through:
- logs
- exception messages
- responses
- telemetry
- screenshots
- generated artifacts
- version control
Use the project's supported secret/configuration mechanism.
Differentiate:
- public identifiers
- configuration
- credentials
- cryptographic secrets
Rotate credentials when exposure is suspected.
10. API Security
For APIs, verify:
- authentication where required
- authorization per resource/action
- strict request validation
- bounded pagination and query parameters
- safe error responses
- rate limits where appropriate
- replay protection where required
- idempotency where duplicate execution is dangerous
- secure token handling
Do not expose internal implementation details in error payloads.
11. Outbound Requests / SSRF
Treat user-influenced destinations as security-sensitive.
When the application performs outbound requests:
- restrict allowed destinations where practical
- validate scheme and host
- reject unsafe protocols
- consider redirects
- protect internal/private network destinations
- apply timeouts
- bound response size where appropriate
Do not fetch arbitrary URLs supplied by users without explicit safeguards.
12. Sessions and Tokens
Use mature platform mechanisms for session and token management.
Verify:
- expiration
- rotation
- revocation where required
- secure transport
- storage
- audience/scope where relevant
- signature/validation rules
- replay considerations
Do not decode a token and treat its claims as trusted without performing the required validation.
13. Sensitive Data
Collect and return only data needed by the operation.
Avoid accidental disclosure through:
- serializers
- debug output
- logs
- stack traces
- API responses
- analytics
- error pages
Explicitly control fields returned across external boundaries when sensitive models contain additional internal data.
14. Errors and Logging
Errors exposed to users should contain enough information to act on the failure without revealing sensitive internals.
Avoid exposing:
- stack traces
- credentials
- tokens
- database details
- filesystem paths
- internal network details
- secrets
- unnecessary personal data
Security-relevant failures may be logged when useful, but logs must not become a secret-leak channel.
15. Configuration
Prefer secure defaults.
Check environment-sensitive settings such as:
- debug mode
- error display
- cookie/session security
- trusted proxies/hosts
- cross-origin policy
- storage permissions
- transport security
- credential loading
Development convenience must not silently weaken production security.
16. Dependencies
Prefer maintained security-critical dependencies.
Do not introduce a new security dependency when the current stack already provides the required capability.
When changing dependencies, consider:
- known vulnerabilities
- abandoned packages
- unnecessary privileges
- transitive risk
- lockfile consistency
17. Cryptography
Do not design custom cryptographic protocols.
Use established implementations.
Use cryptographically secure randomness for security-sensitive values.
Do not substitute ordinary hashes for password hashing.
Do not invent encryption formats when a well-reviewed platform mechanism exists.
Verification
Security verification should be proportional to the changed boundary.
Useful checks may include:
- unauthorized actor denied
- authorized actor allowed
- malformed input rejected
- ownership/tenant isolation preserved
- forged requests rejected
- invalid signatures rejected
- dangerous upload rejected
- rate limit enforced
- secret not exposed
- sensitive response fields absent
- unsafe destination rejected
- expected valid flow still works
Prefer focused tests over broad unrelated rewrites.
Framework Adaptation
After identifying the required control:
- Detect the actual project language/framework from project evidence.
- Inspect the current project stack and available relevant specialist skills.
- Translate the control into established native framework or language mechanisms using repository evidence.
- When stack-specific guidance is unavailable, prefer mechanisms already established by the project.
- Never invent a framework API.
- Never weaken the universal security requirement merely because a convenience API is unavailable.
The core requirement remains authoritative.
Technology-specific guidance only explains how the current stack implements it; the security requirement remains stack-independent.
Active Application Security Assessment
This security core is both a secure-development guide and a post-development security review gate.
Use it for authorized review of applications, services, APIs, changesets, pull requests, and code produced during development.
The goal is to identify exploitable weaknesses, provide evidence, recommend the smallest correct remediation, and verify the fix.
Do not perform destructive exploitation, persistence, credential theft, lateral movement, denial-of-service, or actions beyond the authorized application and environment.
Review Strategy
Prefer evidence over speculation.
When version-control context is available:
- inspect the changed files and diff first
- identify affected trust boundaries and entry points
- inspect reachable surrounding code
- follow data from source through transformations to sensitive sinks
- determine whether existing controls actually prevent exploitation
- verify remediation after changes are applied
Do not report a vulnerability solely because a dangerous API or pattern exists. Establish reachability, attacker influence, missing control, and meaningful impact whenever practical.
Stack Discovery
Before applying technology-specific assumptions, determine from project evidence:
- language
- framework
- framework/runtime version
- package manager
- authentication mechanism
- persistence layer
- exposed interfaces
- deployment/runtime characteristics relevant to security
The core remains framework agnostic.
If a matching adapter exists, use it only to translate these requirements into native framework mechanisms.
Attack Surface and Trust Boundaries
Identify relevant externally influenced surfaces, including:
- HTTP routes and API endpoints
- form and query input
- headers and cookies
- uploaded files
- webhook payloads
- external API responses
- message/event consumers
- command or job input
- import files
- authentication state
- authorization context
- database-derived content that originally came from untrusted users
Identify sensitive sinks such as:
- database queries
- operating-system commands
- template/rendering output
- filesystem access
- outbound network requests
- redirects
- authentication/session state
- authorization decisions
- serialization/deserialization
- secrets
- logs
- privileged business operations
Trace relevant flows as:
source -> validation/transformation -> authorization -> sink
Required Security Checks
Authentication
Review:
- authentication bypass
- insecure account recovery
- session lifecycle
- token lifecycle
- credential handling
- session fixation
- insecure remember-me behavior
- missing invalidation where required
Authorization
Verify authorization at the operation and resource boundary.
Check for:
- IDOR / broken object-level authorization
- privilege escalation
- missing tenant or ownership checks
- authorization performed only in the UI
- role checks that do not protect the underlying resource
Authentication alone is never sufficient authorization.
Injection
Review attacker-controlled data reaching interpreters or query builders.
Consider:
- SQL/query injection
- command injection
- expression injection
- template injection
- header injection
- unsafe dynamic evaluation
Prefer parameterization and native safe APIs.
Output and XSS
Review untrusted data rendered into:
- HTML
- attributes
- script contexts
- URLs
- other executable contexts
Use context-appropriate output encoding.
Avoid disabling safe escaping without explicit justification.
Request Forgery
For state-changing browser requests, verify appropriate anti-forgery protections where the authentication model requires them.
Do not rely only on request method or frontend behavior.
SSRF and Outbound Requests
Treat attacker-influenced destinations as a security boundary.
Review:
- URL parsing
- protocol restrictions
- redirect following
- private/internal address access
- cloud metadata access
- DNS rebinding considerations
- credential forwarding
Prefer explicit destination allowlists when the business flow permits it.
Files and Paths
For uploads, downloads, archives, and filesystem access review:
- filename trust
- path traversal
- extension versus actual content
- MIME/content validation
- size limits
- storage location
- executable files
- overwrite behavior
- archive extraction paths
- authorization for file retrieval
Generate server-side storage names when appropriate.
Secrets and Tokens
Never intentionally expose secrets through:
- source control
- API responses
- frontend bundles
- exception pages
- logs
- diagnostic output
Use environment or platform secret facilities appropriate to the stack.
APIs and Data Exposure
Review:
- excessive fields
- mass assignment / unintended writable fields
- enumeration
- missing authorization
- unsafe pagination
- unbounded responses
- verbose errors
- internal identifiers or metadata exposed unnecessarily
Return only data required by the consumer.
Rate Limiting and Resource Abuse
Review expensive or abuse-prone operations such as:
- authentication
- password recovery
- OTP or verification
- search
- exports
- uploads
- AI/model calls
- external API calls
- bulk operations
Consider:
- rate limits
- bounded pagination
- input size
- query complexity
- execution time
- concurrency
- memory consumption
Do not use load generation or denial-of-service techniques as part of a normal security review.
Webhooks and Machine-to-Machine Requests
Where relevant verify:
- authenticity
- signature validation
- timestamp or freshness
- replay protection
- duplicate delivery handling
- idempotency
- secret handling
- authorization of resulting side effects
Logging and Error Handling
Logs must contain enough evidence for operations without leaking:
- passwords
- session identifiers
- access tokens
- API keys
- private cryptographic material
- unnecessary personal or sensitive data
Do not expose internal stack traces or implementation details to untrusted clients in production environments.
Dependencies and Configuration
Review relevant risks from:
- vulnerable dependencies
- unsupported versions
- unsafe defaults
- debug/development configuration
- overly broad permissions
- exposed administrative interfaces
- insecure transport configuration
- accidentally committed secrets
A dependency finding should be tied to the version actually used by the project.
Cryptography
Do not design custom cryptography when established platform mechanisms exist.
Review:
- obsolete algorithms
- weak randomness
- hard-coded keys
- insecure key storage
- incorrect encryption/signing usage
Dynamic Verification
When an authorized test or staging environment exists, static findings may be verified dynamically.
Dynamic verification should be:
- minimal
- reproducible
- non-destructive
- scoped to the suspected vulnerability
- sufficient to establish whether the weakness is exploitable
Do not escalate beyond the evidence needed to validate the issue.
If dynamic verification is unavailable, state the limitation instead of inventing exploitability evidence.
Evidence Standard
A confirmed finding should describe, where applicable:
- affected component
- attacker-controlled source
- relevant execution path
- sensitive sink or security decision
- missing or ineffective control
- realistic impact
- reproducible evidence
- remediation
- verification method
Distinguish between:
- confirmed vulnerability
- likely vulnerability requiring verification
- defensive improvement / hardening
- informational observation
Do not inflate hardening recommendations into confirmed vulnerabilities.
Severity
Prioritize findings using exploitability and impact together.
Typical levels:
- CRITICAL: realistic path to severe compromise with little additional prerequisite
- HIGH: significant confidentiality, integrity, authorization, or privileged-operation impact
- MEDIUM: exploitable weakness with meaningful but constrained impact
- LOW: limited-impact weakness or defense-in-depth issue
Severity must follow evidence, not vulnerability names alone.
Remediation
Prefer the smallest fix that removes the root cause.
Remediation should:
- protect the correct trust boundary
- use native safe mechanisms when available
- preserve intended application behavior
- include regression protection when practical
Avoid broad rewrites when a targeted correction is sufficient.
Re-Test
After remediation:
- repeat the original security check
- verify the vulnerable path is no longer exploitable
- verify intended behavior still works
- verify nearby equivalent paths when warranted
A finding is not considered resolved solely because code changed.
Security Review Output
At the end of a dedicated security review, provide concise findings with:
- severity
- location
- evidence
- impact
- remediation
- verification status
Finish with exactly one gate result:
SECURITY REVIEW: PASS
Use PASS when no actionable confirmed security issue remains within the reviewed scope.
Or:
SECURITY REVIEW: NEEDS_FIX
Use NEEDS_FIX when one or more actionable security issues remain.
When review coverage is materially incomplete, explicitly state the coverage limitation before the gate result.
Bundled Resources
This skill may include reusable resources in its own directory.
Security Gate
For commit-aware or staged-diff security review, use:
scripts/security-gate.mjs
An optional Git hook installer is available at:
scripts/install-security-gate.ps1
Use these helpers only when the execution environment supports them.
The security analysis rules in this SKILL.md remain usable even when the helper scripts cannot be executed.
Framework References
Framework-specific implementation guidance may exist under:
references/
Before using one:
- detect the project's actual framework from repository evidence
- load only the matching reference
- keep this security core authoritative
If no matching reference exists, continue using the framework-agnostic security requirements.
Do not assume a framework merely because a framework reference is bundled with this skill.