security-and-hardening

Overview of security-and-hardening skill

The security-and-hardening skill helps you harden application code against common vulnerabilities before they ship. It is best for developers, reviewers, and AI agents working on features that accept untrusted input, manage sessions, store sensitive data, or call external services. If you need the security-and-hardening skill for Security Audit work, this is the right fit when you want implementation-level checks, not just a generic security checklist.

What this skill is for

Use security-and-hardening when the job is to reduce exploit risk in real code paths: request handling, auth flows, database access, file uploads, webhooks, and payment or PII logic. The skill is centered on boundary control, so it focuses on what must happen at the edge of the system before data reaches storage or business logic.

What makes it useful

The main value is practical guardrails: validate input early, parameterize queries, escape output, protect sessions, enforce HTTPS, and avoid unsafe shortcuts around auth or secrets. That makes the security-and-hardening guide useful when you want fewer guesses and more concrete defensive moves.

When it is a good fit

Choose this skill if your prompt involves hardening an existing feature, reviewing risky code, or turning a rough “make this secure” request into concrete changes. It is especially relevant when a workflow includes security-and-hardening usage across backend routes, client-facing forms, or integrations with third-party APIs.

How to Use security-and-hardening skill

Install and inspect the source

For security-and-hardening install, use:

npx skills add addyosmani/agent-skills --skill security-and-hardening

Start with SKILL.md, then read the frontmatter and the sections that define when to use the skill and what must always happen. This repository has no supporting rules/, resources/, or scripts, so SKILL.md is the main source of truth.

Give the skill the right input

The security-and-hardening skill works best when you provide the exact surface area and threat context. Instead of saying “secure this app,” say what is exposed, what data is involved, and what stack constraints exist. Good input names the feature, the trust boundary, and the risk:

Harden this password reset endpoint. It uses Express, PostgreSQL, and email links. Focus on input validation, token handling, rate limiting, and secure cookie/session behavior.

That is better than a vague prompt because it gives the model a boundary, a data type, and a target outcome.

Follow a review-first workflow

A reliable security-and-hardening usage pattern is: identify inputs, map trust boundaries, check storage and output handling, then verify auth and transport protections. Ask for changes in the order the attack surface appears, not in random issue order. For Security Audit tasks, this helps the skill produce findings that are tied to code paths instead of generic advice.

Watch the highest-impact constraints

The repository emphasizes non-negotiables: validate at the boundary, parameterize queries, encode output, use secure cookies, and avoid plaintext secrets. When you use the skill, be explicit about framework behavior that could weaken those controls, such as disabled escaping, custom auth middleware, or direct SQL string building.

security-and-hardening skill FAQ

Is this only for large audits?

No. security-and-hardening is also useful for small features that touch sensitive data. A single webhook handler or upload form can justify the skill if it accepts outside input or changes trust boundaries.

How is it different from a normal prompt?

A normal prompt may ask for “security best practices” and get generic advice. The security-and-hardening skill is more decision-oriented: it pushes the response toward boundary validation, defensive defaults, and concrete fixes that match the code path being changed.

Is it beginner-friendly?

Yes, if you can describe the feature clearly. Beginners get the most value by providing the route, data type, and framework. The skill can then turn that into a more actionable hardening plan than a general security checklist.

When should I not use it?

Do not use it for purely cosmetic changes, low-risk static content, or tasks where security is not part of the acceptance criteria. If the code does not handle user input, secrets, sessions, or external calls, the security-and-hardening skill is probably unnecessary.

How to Improve security-and-hardening skill

Be specific about the attack surface

Better inputs produce better hardening guidance. State what can be attacked, what data is sensitive, and where the boundary is. For example, “review this file upload flow for path traversal, MIME spoofing, and unsafe storage” is stronger than “make uploads safer.”

Ask for checks, not slogans

The most useful security-and-hardening skill outputs name exact controls: parameterized SQL, output encoding, cookie flags, CSRF handling, secrets management, and transport security. If you want better results, ask for code-level changes plus the reason each change blocks a realistic attack.

Iterate from risk to implementation

Start with the highest-risk path, then refine. A strong security-and-hardening guide workflow is: first request a threat review, then ask for a patched version, then ask for a final pass on headers, auth edge cases, and dependency risk. This reduces the chance that the first answer over-focuses on low-value issues.

Share stack details that affect fixes

Mention the framework, auth library, database, and deployment environment. Security hardening differs across Express, Next.js, Rails, Django, and serverless setups, especially for sessions, headers, and input validation. The more precise the stack, the fewer mismatched recommendations you get from security-and-hardening for Security Audit work.