/security-guidance

name: security-guidance
description: Security-first development guidance based on OWASP ASVS (Application Security Verification Standard). Use this skill automatically when planning or implementing any code that touches user input, authentication, data persistence, network communication, file I/O, cryptography, or access control. This skill ensures all generated code adheres to industry-standard security practices with explicit references to applied guidance.

Security Guidance

Core Principle

Security is a first-class requirement. Before completing any plan or producing any code that touches security-sensitive operations, consult the ASVS reference index below and apply all relevant guidance.

**All generated code and plans must demonstrably adhere to the selected guidance, with safe defaults and explicit inline citations.**

Workflow

1. **Identify relevant sections** — Match the current task against the `When to use:` triggers in the index below. A task may match multiple sections; apply all of them. 2. **Read the reference file** — For each matched section, read the full reference file listed at the end of its index entry to get the complete verification requirements. 3. **Apply the guidance** — Implement the requirements. Default to the most secure option when the requirements allow choice. Apply all Level 1 requirements as a minimum baseline; note any Level 2 or Level 3 requirements that are relevant but not yet implemented. 4. **Cite applied requirements inline** — In code comments or plan notes, reference each requirement you satisfy: `// ASVS 6.2.4: password checked against top-3000 list`.

Escalation

If no section in the index matches a task that involves security-sensitive operations, or if guidance is conflicting or unclear, **stop and flag the gap** before proceeding. Do not guess or paraphrase guidance — escalate instead.

If the index below is empty, report that the reference index failed to load and list which ASVS chapters are likely relevant based on the task description.

Reference Index

V1.1 Encoding and Sanitization Architecture

Architectural requirements for the order and placement of encoding, escaping, and decoding operations.

When to use:

• designing a data processing pipeline that handles untrusted input
• deciding where in the request/response lifecycle to encode or escape data
• storing data that will later be rendered in different output contexts

See `data/asvs/V1.1.md` for detailed guidance.

V1.2 Injection Prevention

Output encoding and escaping requirements to prevent injection into interpreters (SQL, HTML, JS, OS, LDAP, etc.).

When to use:

• building database queries (SQL, NoSQL, HQL, Cypher, XPath, LDAP)
• constructing OS commands or shell scripts with dynamic data
• building URLs or redirects with user-supplied values
• rendering user input inside HTML, CSS, or JavaScript
• processing LaTeX input
• evaluating regular expressions containing user-supplied patterns
• generating CSV, XLS, or spreadsheet exports with user data

See `data/asvs/V1.2.md` for detailed guidance.

V1.3 Sanitization

Requirements for sanitizing untrusted HTML and dynamic content when encoding is not applicable.

When to use:

• accepting rich text or HTML input from users (e.g., WYSIWYG editors)
• using eval() or dynamic code execution with user-supplied content
• rendering user-submitted markup where encoding alone is insufficient

See `data/asvs/V1.3.md` for detailed guidance.

V1.4 Memory, String, and Unmanaged Code

Requirements for safe memory handling and string operations in unmanaged or low-level code.

When to use:

• writing or integrating unmanaged code (C, C++, assembly)
• using unsafe memory operations, pointer arithmetic, or raw buffers
• calling native libraries or FFI from a managed language
• handling string operations in low-level or performance-critical code

See `data/asvs/V1.4.md` for detailed guidance.

V1.5 Safe Deserialization

Requirements for safely deserializing data from untrusted or external sources.

When to use:

• deserializing objects or data structures from untrusted sources
• accepting serialized data via network, file upload, or API payloads
• using Java serialization, Python pickle, PHP unserialize, or similar mechanisms
• processing binary or text-based serialization formats (XML, JSON, YAML, MessagePack)

See `data/asvs/V1.5.md` for detailed guidance.

V2.1 Validation and Business Logic Documentation

Requirements for documenting expected inputs and business logic rules.

When to use:

• documenting what inputs an application accepts and their expected formats
• defining business rules and workflow constraints for a feature

See `data/asvs/V2.1.md` for detailed guidance.

V2.2 Input Validation

Requirements for validating input data at application boundaries.

When to use:

• processing any user-supplied input at an application boundary
• validating that inputs match expected types, formats, lengths, or value ranges
• checking data received from external systems or APIs

See `data/asvs/V2.2.md` for detailed guidance.

V2.3 Business Logic Security

Requirements for securing business workflows against manipulation, skipping steps, or race conditions.

When to use:

• implementing multi-step workflows or transaction sequences
• enforcing ordering or timing constraints between operations
• handling financial transactions, inventory updates, or state machines
• implementing features where users should not be able to skip or replay steps

See `data/asvs/V2.3.md` for detailed guidance.

V2.4 Anti-automation

Requirements for protecting against automated abuse, scraping, and excessive requests.

When to use:

• adding rate limiting to endpoints or operations
• protecting forms or APIs from automated abuse or credential stuffing
• implementing CAPTCHA or bot detection on public-facing endpoints
• limiting how many times an operation can be performed per user or IP

See `data/asvs/V2.4.