App Security Minimums for Contractors: One‑Page Secure Defaults Pack (Auth, Storage, Secrets, Data‑in‑Transit)

Require server‑side, standards‑based authentication as the default: OAuth2/OIDC for user flows and short‑lived, scoped access tokens for machine-to-machine calls. Do not accept custom home‑grown password protocols or client‑only checks. Favor third‑party identity providers (Auth0, Firebase Auth, or your cloud provider’s managed identity) only when they are configured to use secure defaults (PKCE for public clients, refresh token rotation, token scope minimization).

Mandate multi‑factor authentication (MFA) for admin and privileged accounts and require session management rules: short access token lifetimes, explicit refresh token revocation on logout, and server‑side session invalidation. For password guidance, reference NIST’s outcome‑based rules (allow long passphrases, avoid forced periodic rotation, screen against known‑compromised lists) and prefer passwordless flows where practical.

bullets:[

Require that all customer data and secrets at rest are encrypted with industry‑standard algorithms (AES‑GCM, or equivalent) and that encryption keys are not stored in code or in the same storage as the ciphertext. If using cloud provider storage (S3, GCS, Blob), mandate server‑side encryption enabled and that default bucket/object ACLs are private. For databases, require Transparent Data Encryption (TDE) or column‑level encryption for sensitive fields (PII, credentials).

Ask contractors to provide key management details: which KMS (cloud native or HSM) is used, who has access, and the rotation policy. Keys that protect production data must be stored and managed separately from application code and developer laptops; ephemeral developer credentials should be discouraged. Include an explicit prohibition on committing secrets (keys, certificates, DB passwords) to source control.

bullets:[

Require a centralized secrets manager (HashiCorp Vault, cloud secret managers, or equivalent) for all runtime secrets. Secrets must be injected into runtime environments via environment variables or provider‑managed secret mounts — never baked into container images or artifacts. The contractor must demonstrate role‑based access control (RBAC) on secrets and provide audit logs showing who accessed which secret and when.

Define acceptable secret lifecycles: short lived where possible (ephemeral credentials), automatic rotation for high‑risk secrets, and strict approval processes for creating long‑lived secrets. For shared credentials between services, require scoped service accounts and use identity federation or short‑lived tokens instead of long static keys.

bullets:[

Mandate TLS for all external and internal traffic. Define minimum acceptable TLS versions and ciphers (e.g., TLS 1.2+ with strong ciphers, prefer TLS 1.3 where supported) and disallow insecure ciphers and self‑signed certs in production. Require certificate management: short lifetimes, automated renewal, and use of managed PKI or ACME where practical.

For service‑to‑service calls inside your environment, require mTLS or strong mutual authentication patterns when services cross trust boundaries. Enforce network segmentation so that high‑privilege services live in restrictive subnets and require explicit ingress/egress rules. Document acceptable fallback behavior for unavailable TLS (reject, not downgrade).

bullets:[

Require structured, centralized logging with retention and access controls. Logs must not contain full secrets or plaintext PII; implement redaction or tokenization at the source. Contractors should ship logs to a managed SIEM or centralized logging bucket with RBAC and monitoring alerts for authentication failures, privilege escalations, and repeated access denials.

Attach these eight acceptance checks to every delivery as pass/fail items: 1) No secrets in source control (run a secret scan); 2) TLS enforced for all endpoints (no HTTP); 3) MFA enabled for admin accounts; 4) Production keys in KMS, not repo; 5) Short‑lived tokens or refresh rotation enabled; 6) Bucket/object ACLs set to private; 7) Audit logs available for auth and secret access; 8) Penetration test or dependency scan run and results attached. Make passing these checks a gate for payment or sign‑off to eliminate late security rework.

bullets:[