Security Baseline

---
name: security-baseline
description: Applies a language-agnostic, vendor-neutral secure-engineering baseline (aligned to OWASP, CIS Benchmarks, and NIST CSF / CISA Cybersecurity Performance Goals) whenever writing, reviewing, or explaining code that touches authentication, secrets, encryption, file uploads, APIs, databases, network or cloud configuration, logging, dependencies, or deployment. Use this whenever the user asks to add an endpoint, handle user or customer data, store credentials, connect to a database, expose a public service, set up CI/CD, write infrastructure config, or review a diff for security issues, even if they don't say the word "security". Also use when the user asks "is this secure", "what's best practice for X", "how should I store this", or is clearly building something that will hold real user data or run in production.
---

# Security Baseline

A working default for anyone shipping software, so a small team doesn't have to
rediscover secure-by-default practice project by project. Apply it silently as
you write or review code, the same way you'd apply a style guide: don't lecture
the user about it, just do the secure thing and mention it in passing if it
changes what you'd otherwise have written.

None of this is exotic. It's the intersection of OWASP's proactive controls,
the parts of the CIS Benchmarks that apply to application code, and NIST
CSF / CISA's baseline goals for under-resourced teams, compressed into rules
that are cheap to follow from day one, on any cloud, in any language.

**How to use the sections below:** jump to the one that matches what you're
building. Each rule is short on purpose, if you need the reasoning, it's
usually one Google search away (OWASP Cheat Sheet Series is the best source).
Treat every rule as a default, not a debate, unless the user's project has a
concrete reason to deviate, in which case say so explicitly rather than
silently skipping it.

## Secrets & credentials

- Never write a password, API key, token, or private key directly into source
  code, config committed to git, or a Dockerfile. Read it from an environment
  variable at minimum; use a secrets manager (cloud-native one, Vault, etc.)
  once the project is running anywhere shared.
- If you're adding a new env var, add it to `.env.example` (or equivalent)
  with a placeholder value and a one-line comment, and confirm the real file
  (`.env`, `.env.local`) is in `.gitignore`.
- Every credential, API key, and service account needs an obvious owner and a
  reason it exists. If you're generating one, say what it's for and how to
  rotate it.
- Prefer short-lived, cloud-native identity (IAM roles, managed identities,
  workload identity) over long-lived static keys wherever the platform
  supports it.

## Encryption & data protection

- Encrypt data in transit by default: HTTPS/TLS for anything that leaves a
  process, no plaintext HTTP for real traffic.
- Encrypt data at rest using whatever the storage layer offers natively
  (it's usually a single setting on managed databases and object storage) and
  turn it on rather than assuming it's already on.
- Before writing code that touches personal data, payment data, health data,
  or anything a user would consider private, ask (or infer from context) what
  category it falls into, and keep that in mind for retention and access
  decisions later.
- Use masked, synthetic, or seeded data outside production. Never suggest
  copying real user data into a dev or staging environment to "test with
  real data."
- Don't log secrets, tokens, passwords, or personal data. If a log line would
  contain any of those, redact or omit the field.

## Authentication & access control

- Prefer a central identity provider (whatever the project already uses: an
  OAuth/OIDC provider, the cloud's own IAM, an existing SSO setup) over a
  new, custom username/password table, unless there's a specific reason to
  own auth directly.
- Enforce MFA on anything administrative or privileged if the identity
  provider supports it, and mention it if it's missing.
- Use named, individual accounts for anything interactive. Flag shared or
  generic logins as a problem, not a convenience.
- Apply least privilege by default: a service account, API key, or database
  user should have exactly the access it needs and nothing broader "to be
  safe later."

## API & service communication

- Validate every external input (request bodies, query params, headers,
  file uploads) before it reaches business logic. Don't trust client-side
  validation alone.
- Rate-limit public and authenticated endpoints against abuse, not just
  against load.
- Return clean, generic error messages to callers. Never leak stack traces,
  SQL, internal file paths, or framework version strings in a response, log
  the real detail server-side instead with a correlation ID the user can
  quote back.
- Authenticate and encrypt service-to-service calls the same way you would
  external ones. "It's internal" is not a reason to skip auth.
- Version APIs explicitly and document them (OpenAPI/Swagger or equivalent)
  so breaking changes are visible.

## File uploads & user content

- Restrict uploads to an explicit allow-list of file types and a size limit.
  Never accept executable extensions on a general-purpose upload endpoint.
- Store uploaded files in object storage that isn't directly public-writable
  or executable, not on the app server's local disk.
- Scan uploads for malware before they're processed, shared, or served back
  to another user, if the project has any budget for it; at minimum, never
  serve an uploaded file with a content-type that lets a browser execute it.

## Database & data handling

- Schema changes go through versioned migrations with a rollback path, never
  a manual edit against a live database.
- Application database users get read/write access to their own tables, not
  schema-owner or superuser privileges. Reserve DDL permissions for the
  deployment pipeline.
- Use parameterized queries or an ORM's query builder, never string-concatenated
  SQL, full stop.
- Index what you filter and join on, and watch for N+1 query patterns when
  reviewing an ORM-heavy change.

## Dependencies & supply chain

- Commit the lockfile. Deterministic builds aren't optional.
- Stick to actively maintained packages and supported language/runtime
  versions. Flag it if the user is about to add a dependency that's
  unmaintained, has no lockfile support, or duplicates something already in
  the project.
- If the project has dependency scanning available (`npm audit`, `pip-audit`,
  Dependabot, Renovate, etc.), treat a Critical or High finding as something
  to fix now, not defer.

## Logging & observability

- Emit structured logs (JSON is the common choice) rather than free-text,
  once a project is past the prototype stage.
- Every service that runs continuously should expose a basic health-check
  endpoint.
- Propagate a request/trace ID through a call chain so a single failure can
  be followed end to end.

## Network & cloud configuration

- Deny by default on inbound network rules; open only the ports a service
  actually needs.
- Don't expose a database, cache, or admin interface directly to the public
  internet. Put it on a private network/subnet, or in front of a bastion,
  VPN, or the cloud's session-manager equivalent.
- If you're writing infrastructure config, write it as code (Terraform,
  Pulumi, CloudFormation, CDK, etc.) rather than describing manual console
  steps, so the config is reviewable and repeatable.
- Cloud-native DDoS protection is usually free and on by default, don't turn
  it off. A Web Application Firewall in front of a public endpoint is a
  reasonable default once there's real user traffic to protect.

## CI/CD & release

- Every change to a shared branch should pass through review and automated
  checks (lint, test, build) before merging. Don't suggest a direct push to
  `main` as a shortcut.
- Secrets scanning and dependency scanning belong in CI, not just on a
  developer's machine.
- Build once, promote the same artifact through environments, rather than
  rebuilding per environment.
- Tag releases meaningfully (semantic versioning is a fine default) and make
  sure there's a known rollback path before something ships, not after it
  breaks.

## Incident basics

- If you notice (or the user mentions) a leaked credential, exposed data, or
  a suspected breach while working, say so plainly and immediately, don't
  bury it in a long diff summary.
- The first response to an exposed secret is to rotate it, then investigate
  the root cause. Order matters.

## When something genuinely doesn't apply

A rule that's irrelevant to what's being built (there's no file upload
feature, no database, no public endpoint) simply doesn't come up, skip it
without comment. A rule that applies but can't be fully satisfied yet (no
budget for malware scanning, no dedicated ops person for 24/7 monitoring) is
different: say so explicitly, suggest the smallest real step available (a
free or built-in equivalent is usually good enough to start), and don't
silently pretend the gap doesn't exist.