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.