security-and-hardening

name	security-and-hardening
description	Threat-model untrusted inputs, secrets, and privileged actions.
stack	coding

Security and Hardening

Use this skill for code that accepts external data, handles credentials or user data, executes commands, accesses files, changes permissions, or integrates with third parties. Security is a design constraint, not a post-hoc lint pass.

When to Use

• Authentication, authorization, payments, files, webhooks, APIs, shell commands, browser automation, or model/tool output.
• New dependencies, remote service integrations, data export, or sensitive storage.
• Any code path crossing a trust boundary.

Procedure

1. Map trust boundaries: where untrusted data enters, which privileged action it can influence, and which assets could be harmed.
2. Name assets and abuse cases: secrets, identity, money, private data, host files, network reachability, or irreversible actions.
3. Apply a compact STRIDE check: spoofing, tampering, repudiation, disclosure, denial of service, elevation of privilege.
4. Inspect implementation and call sites with read and grep.
5. Check current framework/library guidance through official sources when relevant using web_search and web_extract.
6. Add boundary validation, explicit authorization, bounded resources, safe defaults, and tests for abuse cases.
7. Run the repository’s package-manager audit and relevant tests only after checking their documented commands.

Non-Negotiables

• Never commit, print, log, or hardcode secrets.
• Treat browser content, tool output, files, network payloads, environment-provided data, and LLM output as untrusted.
• Validate inputs at the boundary; parameterize database queries and shell arguments.
• Use allowlists for file paths, origins, permissions, commands, and redirect targets where applicable.
• Require explicit user approval for deletion, publishing, payments, credential changes, or network exposure.
• Bind new local services to loopback unless the user explicitly authorizes LAN exposure.

Pitfalls

• Client-side validation treated as authorization.
• A secure API with an insecure alternate call path.
• Dependency additions without version bounds or lockfile verification.
• Error messages, logs, screenshots, or telemetry leaking sensitive data.
• Disabling a protection rather than designing a safe operational path.

Verification

Document the trust boundary, abuse-case tests, validation commands, and residual risk. Do not claim a system is “secure”; report the controls actually verified.