菜单
Use when writing code that processes user input, manages authentication or authorization, constructs database queries, handles file operations, interacts with external data, exposes API endpoints, or manages secrets - any code that crosses a trust boundary
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when starting any conversation - establishes how to locate and invoke skills, mandating Skill tool usage before ANY response including clarifying questions
Use when building ANY website, web app, landing page, or web-based UI - searches real template marketplaces for professionally designed layouts in the user's industry or niche, then extracts layout structure, color palettes, typography choices, and section sequences as the design blueprint instead of generating from assumptions
Use when about to build any feature, library, or system - searches GitHub and package registries for existing implementations to study, harvest patterns from, or use directly instead of building from scratch
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
Use when making technology, hosting, or infrastructure decisions — recommends services, databases, and deployment strategies based on project requirements and what the user actually has available
Use when starting a session, running shell commands, installing packages, or diagnosing platform-specific failures - detects OS, shell, runtime, package manager, and toolchain before any command execution
| name | security-protocol |
| description | Use when writing code that processes user input, manages authentication or authorization, constructs database queries, handles file operations, interacts with external data, exposes API endpoints, or manages secrets - any code that crosses a trust boundary |
Security is not a phase you bolt on. Every line of code is a security decision.
Core principle: Never trust data from outside your trust boundary. Validate at every boundary crossing.
No exceptions. No workarounds. No shortcuts.
NO EXTERNAL DATA REACHES A SYSTEM CALL, QUERY, OR OUTPUT WITHOUT VALIDATION AND SANITIZATION
When data crosses a trust boundary, it must be validated before consumption. This is absolute.
Mandatory when writing code that:
This is not discretionary. Security awareness is woven into development, not applied afterward.
BEFORE shipping ANY code that handles external data:
1. IDENTIFY: Where does data enter the system? (Trust boundary)
2. VALIDATE: Is input validated at the boundary?
3. SANITIZE: Is output encoded for its target context?
4. AUTHORIZE: Is access control verified before the action?
5. PROTECT: Are secrets, tokens, and keys managed safely?
Omit any step = vulnerability shipped
Every endpoint must verify: Can THIS user perform THIS action on THIS resource?
# VULNERABLE: Checks authentication but not authorization
GET /api/accounts/456/profile # User 123 views user 456's private data
# SECURE: Verify resource ownership
if resource.owner_id != authenticated_user.id:
return 403 Forbidden
| Verification | Method |
|---|---|
| Authentication | Is the user who they claim to be? |
| Authorization | Is this user permitted to perform this action? |
| Resource ownership | Does this user own this specific resource? |
| Role enforcement | Server-side role check; never trust client-provided role claims |
Default posture: deny. If no explicit rule grants access, access is denied.
| Required Practice | Prohibited Practice |
|---|---|
| bcrypt/scrypt/argon2 for password hashing | MD5, SHA1, SHA256 for passwords |
| TLS everywhere (HTTPS) | HTTP for anything sensitive |
| Cryptographically secure RNG for tokens | Math.random() for security tokens |
| Encrypt sensitive data at rest | Store sensitive data in plaintext |
| Use established cryptographic libraries | Implement custom cryptography |
Never concatenate external input into queries, commands, or templates.
| Injection Vector | Prevention |
|---|---|
| SQL injection | Parameterized queries / prepared statements. Always. |
| NoSQL injection | Type-check inputs; use ODM query builders |
| Command injection | Avoid shell execution. If unavoidable: allowlist arguments, never interpolate |
| LDAP injection | Escape special characters; use parameterized queries |
| Template injection | Use auto-escaping template engines |
-- VULNERABLE: String concatenation
SELECT * FROM users WHERE email = '" + userInput + "'
-- SECURE: Parameterized query
SELECT * FROM users WHERE email = $1
This is non-negotiable. There is no scenario where string concatenation in queries is acceptable.
| Checkpoint | Action |
|---|---|
| Default credentials | Replace all defaults before deployment |
| Debug features | Disable debug mode, admin consoles, and verbose errors in production |
| Error verbosity | Never expose stack traces, SQL errors, or internal paths to users |
| Directory listing | Disable on all web servers |
| Security headers | Set them (see Security Headers section) |
| CORS policy | Restrict to specific origins; never * for credentialed requests |
BEFORE adding any dependency:
1. Is it actively maintained? (Last commit within 6 months)
2. Are known vulnerabilities published? (npm audit, snyk, dependabot)
3. Is it widely adopted? (Download counts and stars are signals, not guarantees)
4. Is it actually necessary? (Do not add a dependency for a single utility function)
Execute npm audit / pip audit / cargo audit regularly. Remediate critical and high findings immediately.
| Requirement | Implementation |
|---|---|
| Password storage | bcrypt/scrypt/argon2 with unique salts |
| Session tokens | Cryptographically random, httpOnly, secure, sameSite flags |
| Brute-force protection | Lock account after 5-10 consecutive failures |
| Multi-factor authentication | Support TOTP minimum for sensitive applications |
| Password policy | Minimum 8 characters; cross-reference against breach databases |
| Session lifecycle | Expire sessions; invalidate on password change |
eval(), no pickle.loads() on user input)| Log | Never Log |
|---|---|
| Authentication attempts (success and failure) | Passwords or authentication tokens |
| Authorization denials | Complete credit card numbers |
| Input validation failures | Personally identifiable information without purpose |
| System errors | Encryption keys or secrets |
Set these on every HTTP response:
Content-Security-Policy: default-src 'self'; script-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Begin restrictive and relax only when a specific requirement demands it.
NEVER:
- Embed secrets in source code
- Commit .env files to version control
- Write secrets to log output
- Transmit secrets in URL query parameters
- Store secrets in client-side code
ALWAYS:
- Use environment variables or dedicated secret managers
- Add .env to .gitignore BEFORE the first commit
- Rotate secrets on a defined schedule
- Use distinct secrets per environment
- Audit secret access
For every input field:
| Rationalization | Truth |
|---|---|
| "Internal tool, no attacker" | Internal tools get compromised. Internal users make mistakes. Insider threats are real. |
| "We will add security later" | Security is not a feature. Retrofitting it costs 10x more than building it in. |
| "The framework handles it" | Frameworks have escape hatches. Know exactly what your framework does and does not protect. |
| "Input validation is excessive" | Every injection attack in history started with unvalidated input. |
| "It is just a prototype" | Prototypes become production systems. Secure from the beginning. |
| "Too complicated, slows development" | Data breaches slow development permanently. |
| "Nobody would do that" | Attackers do exactly that. Assume all input is hostile. |
eval() or exec() on user-provided data* CORS policy with credentialsEvery item on this list is a security vulnerability. Remediate before shipping.
Complementary skills:
Trust boundary crossed -> validate input, sanitize output, verify authorization
No exceptions. No "we will add it later." Security ships with the code or the code does not ship.