agentleFS
Sign inStart free
DevelopersGlobalDevelopersGlobal/ai-agent-skills/skills/security-hardening/SKILL.md

security-hardening

Skill216 starsChanged 6 months agoMITView on GitHub

Applies OWASP Top 10, secrets management, and least-privilege principles before any code ships. Security is a build step, not an afterthought.

We split this skill into the rules it gives an agent

9 rules. 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 20 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before any code involving user input

    line 15
  2. Distinctive:

    Before any code touching authentication, authorization, or sessions

    line 16
  3. Distinctive:

    Before any API endpoint is created or modified

    line 17
  4. Distinctive:

    Before any code that handles secrets, credentials, or PII

    line 18
  5. Distinctive:

    Before any code that makes outbound network requests

    line 19
  6. Distinctive:

    Ask: *Who are the attackers?

    line 25
  7. Distinctive:

    Every piece of external input is validated:

    line 64
  8. Distinctive:

    Verify: All external input has explicit validation with reject-by-default behavior.

    line 71
  9. Distinctive:

    Default deny — access must be explicitly granted, not implicitly inherited.

    line 78

“Common” is measured: kept by at least 6 in 10 of the 20 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Security vulnerabilities are almost always cheaper to prevent than to remediate. This skill embeds security review as a required gate in the development workflow — not a separate audit that happens later (and often never).

When to Use

  • Before any code involving user input
  • Before any code touching authentication, authorization, or sessions
  • Before any API endpoint is created or modified
  • Before any code that handles secrets, credentials, or PII
  • Before any code that makes outbound network requests

Process

Step 1: Threat Model the Change

  1. Ask: Who are the attackers? What are they trying to achieve?
  2. Identify all trust boundaries in the code:
    • Where does user-controlled data enter the system?
    • Where does that data flow?
    • Where is it stored or transmitted?
  3. For each trust boundary, name the top 3 attack vectors.

Verify: You can name at least one realistic attack scenario for this code.

Step 2: Apply OWASP Top 10 Checklist

  1. For each applicable item, confirm it is addressed:
OWASP ItemCheck
A01 Broken Access ControlAuthorization checked at every endpoint? Principle of least privilege applied?
A02 Cryptographic FailuresNo plaintext PII/secrets? Using modern algorithms (AES-256, SHA-256+)? TLS everywhere?
A03 InjectionAll user input parameterized/sanitized? No raw SQL/shell construction?
A04 Insecure DesignThreat model done? Secure defaults? Fail closed (not open)?
A05 Security MisconfigurationNo default credentials? Unnecessary features disabled? Error messages don't leak internals?
A06 Vulnerable ComponentsDependencies up to date? Known CVEs checked?
A07 Auth FailuresBrute-force protection? Session management correct? MFA available?
A08 Software IntegrityDependencies verified? Supply chain integrity?
A09 Logging FailuresSecurity events logged? No secrets in logs? Logs protected from tampering?
A10 SSRFOutbound requests validated? Internal IPs blocked from user-controlled URLs?

Verify: Each applicable item is either addressed or explicitly accepted as a known risk.

Step 3: Secrets Management

  1. No hardcoded secrets — ever. Not even in dev/test code.
  2. Secrets are stored in: environment variables, secrets manager (Vault, AWS Secrets Manager, etc.), or encrypted config.
  3. Secrets are never logged, printed, or included in error messages.
  4. Secrets are never committed to git (check .gitignore and use pre-commit hooks).

Verify: git grep -i 'password\|secret\|key\|token' returns no hardcoded values in code.

Step 4: Input Validation

  1. Every piece of external input is validated:
    • Type check
    • Length/size limits
    • Allowlist of expected values (not blocklist)
    • Reject and log unexpected input — never silently ignore
  2. User-controlled data is never concatenated into SQL, shell commands, HTML, or file paths without proper escaping/parameterization.

Verify: All external input has explicit validation with reject-by-default behavior.

Step 5: Least Privilege

  1. Database connections use the minimum required permissions.
  2. API tokens have the minimum required scopes.
  3. Service accounts cannot access resources they don't need.
  4. Default deny — access must be explicitly granted, not implicitly inherited.

Verify: List every permission granted by this code. Is each one required?

Common Rationalizations (and Rebuttals)

ExcuseRebuttal
"It's internal only"Internal services get breached too. Zero-trust applies internally.
"We'll add auth later"Auth bolted on later is always broken. Design it in from the start.
"The input is from our own frontend"Attackers don't use your frontend. Validate on the server, always.
"It's a dev environment"Dev environments get credentials from prod. Treat them accordingly.
"The secret is in a config file, not code"Is the config file in git? Is it world-readable? Config files are not safe.

Red Flags

  • User input directly interpolated into queries or commands
  • Authentication middleware that can be bypassed
  • Error messages that include stack traces or SQL queries
  • API keys or passwords in source code or comments
  • Missing authorization check on any endpoint
  • HTTP used instead of HTTPS for any sensitive data

Verification

  • OWASP Top 10 checklist reviewed for applicable items
  • No hardcoded secrets (git grep clean)
  • All external input validated (type, length, allowlist)
  • No raw SQL/shell from user input
  • Least privilege applied to all credentials
  • Security events are logged (but secrets are not)
  • Dependency vulnerabilities checked

References

  • OWASP Top 10
  • prompt-injection-defense skill
  • references/security-checklist.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free