---
name: security-best-practices-baseline
description: "A secure-defaults checklist for a new service, covering secrets, auth, dependencies, logging and headers, with a pass or fail verdict on each line. Use when a new service is about to ship and needs a pass or fail check of its secrets, auth, dependencies, logging and headers. Do not use for a deep penetration test or a review of one pull request for vulnerabilities. Related topics: coding, technical."
---

# Security Best Practices Baseline

A secure-defaults checklist for a new service, covering secrets, auth, dependencies, logging and headers, with a pass or fail verdict on each line.

## When to use

Use this skill when a new service is about to ship and needs a pass or fail check of its secrets, auth, dependencies, logging and headers. Do not use it for a deep penetration test or a review of one pull request for vulnerabilities.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Read the pasted description, code and config and write down what is known about each of the five areas, marking gaps as Unknown rather than guessing.
3. State the baseline for each area in one line, adjusted to the strictness level and the sensitivity of the data.
4. Give each area a Pass, Fail or Unknown verdict and quote the exact line or setting that justifies it.
5. Rank the failures by how easily an outsider could exploit them given the stated exposure.
6. Write the smallest fix for each failure so the list can be worked top to bottom.

## Inputs

- **Service description** (longer free text)
- **Stack** (free text, e.g. "Language and framework and host")
- **Handles sensitive data** (choose one: None, Personal data, Payments, Health records, Credentials)
- **Exposed to** (choose one: Internet, Partners only, Internal network only)
- **Relevant code or config** (longer free text)
- **Strictness** (choose one: Prototype, Production, Regulated)

## Output

A five-row verdict table (area, baseline, verdict, evidence) followed by a ranked fix list with one concrete change per failure.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Security Best Practices Baseline

Check this service against a security baseline before it goes live.

- Service description: {{Service description}}
- Stack: {{Stack}}
- Handles sensitive data: {{Handles sensitive data}}
- Exposed to: {{Exposed to}}
- Relevant code or config: {{Relevant code or config}}
- Strictness: {{Strictness}}

Walk five areas in this order: secrets, authentication and authorisation, dependencies, logging, and transport plus response headers. For each area, state the baseline in one line, then give the verdict Pass, Fail or Unknown based only on what was pasted. Secrets must come from the environment or a vault, never from the repository or build logs. Every route must check who the caller is and what they may do. Dependencies need a lockfile and a scan. Logs must carry request context but never tokens or personal data. Responses need HSTS, a content type policy and a tight CORS list. Scale the bar to the strictness level and the data sensitivity. Finish with a ranked fix list: the failures that an internet attacker could use come first, each with the smallest change that closes it.

## Pitfalls

- Marking an area Pass because no problem was visible, when the relevant file was never pasted and the honest verdict is Unknown.
- Applying a regulated-data bar to a prototype, which buries the two failures that matter under twenty that do not.
- Fixing headers first because they are easy, while a hard-coded secret or a missing auth check stays open.