What inputs does it need to generate the audit?

Project Markdown docs, codebase, deployment/config files, and any existing security policies.

Can the audit be automated in CI?

Yes. The output is structured and can be consumed by CI to enforce checks for headers, inputs, secrets, dependencies, and error handling.

hardening-audit

Scanned

npx machina-cli add skill rana/yogananda-skills/hardening-audit --openclaw

Files (1)

SKILL.md

5.3 KB

Read all project markdown documents and examine the codebase to ground in the project's actual stack, dependencies, and deployment architecture.

Hardening Audit

1. HTTP Security Headers

Evaluate each header against the specific architecture — what the app embeds, loads, and connects to:

Header	Check
`Content-Security-Policy`	Does the CSP account for every external resource? Inline scripts? Fonts? Iframes? `report-uri` configured?
`Strict-Transport-Security`	HSTS set with `max-age`, `includeSubDomains`, and `preload` considered?
`X-Content-Type-Options`	`nosniff` set?
`X-Frame-Options`	Appropriate framing policy? `DENY` or `SAMEORIGIN`?
`Referrer-Policy`	Balances analytics needs with privacy?
`Permissions-Policy`	Disables browser features not used (camera, microphone, geolocation)?
`Cross-Origin-Opener-Policy`	Set appropriately for the isolation model?
`Cross-Origin-Resource-Policy`	Set on served assets?

2. Input Validation Boundaries

For every entry point where untrusted data enters the system:

API endpoints — What validates request body, query params, path params? Max lengths? Encoding? Type coercion?
Search queries — What sanitizes before database queries? Before LLM prompt construction? Max query length?
File uploads / ingestion — What validates file type, size, content? Sandboxed processing?
Webhook receivers — Signature verification? Replay protection? Idempotency?
URL parameters — Open redirect prevention? Path traversal?

3. Secret Management

Where do secrets live? Environment variables, Terraform state, CI config, .env files?
Secret rotation — Is there a schedule? Is rotation possible without downtime?
Secret scope — Are secrets scoped to the minimum required service? Or does one key unlock everything?
Secret detection — Is there a pre-commit hook or CI check preventing secret commits?
Secret exposure — Can secrets appear in error messages, logs, or Sentry traces?

4. Dependency Security

Is npm audit / equivalent running in CI? What's the policy for critical vulnerabilities?
Is the lockfile committed and integrity-checked?
Are dependencies pinned or using ranges? What's the update cadence?
Is there an SBOM (Software Bill of Materials)? Does the project need one?
What's the total dependency count? Are there dependencies that could be eliminated?
Are CDN-loaded resources using Subresource Integrity (SRI)?

5. Error Handling & Information Leakage

Do production error responses reveal stack traces, database details, or internal paths?
Does Sentry scrub sensitive fields (connection strings, API keys, query parameters)?
Do logs contain PII, credentials, or session tokens?
Do API error messages help attackers enumerate valid resources?

6. CORS Configuration

Is CORS configured? What origins are allowed?
Are credentials allowed cross-origin? Should they be?
Is the CORS policy the same for all endpoints or differentiated?

7. Database Security

Are all queries parameterized? Any string concatenation in SQL?
Are database roles scoped (read-only for read paths, write for mutation paths)?
Is the connection string using SSL?
Are database extensions enabled with minimum privilege?

8. DNS & Domain Security

DNSSEC enabled?
CAA records restricting certificate issuance?
Domain registrar 2FA?
/.well-known/security.txt present (RFC 9116)?
Email security records (SPF, DKIM, DMARC) if sending email?

Focus area: $ARGUMENTS

For every finding:

What's missing or misconfigured — Specific, not generic
Risk if unaddressed — What attack does this enable?
Remediation — Specific code, config, or process change
Severity — Critical (blocks deployment) / High / Medium / Low

Present as a prioritized checklist. No changes to files — document only.

Output Management

Hard constraints:

Segment output into groups of up to 10 findings, ordered by critical and high-severity gaps first.
If no $ARGUMENTS focus area is given, evaluate only sections 1 (HTTP Headers), 2 (Input Validation), and 3 (Secret Management) — the most commonly exploited surfaces.
Write each segment incrementally. Do not accumulate a single large response.
After completing each segment, continue immediately to the next. Do not wait for user input.
Continue until ALL findings are reported. State the total count when complete.
If the analysis surface is too large to complete in one session, state what was covered and what remains.

Document reading strategy:

Read deployment config, middleware, and security-relevant code paths. Skip business logic unrelated to input/output boundaries.
Do not enumerate every header or endpoint — focus on gaps and misconfigurations.

What hardening measures exist but are incomplete?

What's hardened in development but might not be in production?

Source

git clone https://github.com/rana/yogananda-skills/blob/main/skills/hardening-audit/SKILL.mdView on GitHub

Overview

A production hardening checklist grounded in your actual stack rather than a generic list. It covers HTTP headers, dependency security, secret management, input validation, error handling, CSP, and CORS, all anchored to your architecture. Use it before deployment, after adding external integrations, or at phase boundaries to reduce risk.

How This Skill Works

The skill reads project Markdown documents and the codebase to ground checks in the real stack, deployments, and dependencies. It then generates a concrete audit across HTTP headers, input validation boundaries, secret lifecycle, dependency security, error handling, CSP/CORS, and DNS/domain considerations. The result is a structured checklist you can follow, document, or automate in CI.

When to Use It

Before deployment or release
After adding external integrations or third-party services
At architectural or phase boundaries (milestones)
During security reviews or audits
When updating dependencies or CSP/CORS policies

Quick Start

Step 1: Read the project's Markdown docs and codebase to ground checks in the actual stack
Step 2: Enumerate headers, inputs, secrets, dependencies, and error handling per the app's architecture
Step 3: Produce the structured hardening audit and integrate checks into CI or release docs

Best Practices

Ground checks in the actual stack by reading code and docs, not generic OWASP lists
Run CI checks for secret scanning, SBOM availability, and dependency audits
Pin dependencies with integrity checks (use lockfiles, SBOMs, and SRI where possible)
Validate HTTP headers, CSP, and CORS across all endpoints and assets
Harden inputs and error handling; verify webhook signatures and avoid leaking secrets

Example Use Cases

Audit an API server to ensure CSP, HSTS, and sanitized error responses are in place
CI pipeline runs npm audit or equivalent, maintains a locked dependency graph, and checks SBOM
Secret management review: environment variables and rotation schedule with minimum scope
Webhook receivers implement signature verification, replay protection, and idempotency
Database access uses parameterized queries with SSL-enabled connections and principle-based roles

Frequently Asked Questions

Add this skill to your agents