Security & Compliance exit conditions
Candidate exit conditions for the Security & Compliance type. See the catalog overview for how to adopt these.
Authentication
| Exit condition | What it checks |
|---|---|
|
Every non-public endpoint rejects unauthenticated requests with 401 rather than serving content. |
|
Stored passwords use a memory-hard adaptive hash (bcrypt, scrypt, or Argon2) with a per-user salt, never plaintext or fast hashes. |
|
Repeated failed login attempts trigger throttling or lockout within a bounded number of tries. |
|
Authentication failures return a generic message that does not disclose whether the username or password was wrong. |
|
Accounts flagged as privileged require a second factor before authentication succeeds. |
|
No default, shipped, or hardcoded credentials authenticate against any environment. |
|
Credentials are only accepted over TLS and never appear in URLs, query strings, or GET parameters. |
|
Submitted passwords are checked against a minimum length and a breached-password denylist before acceptance. |
|
Credential comparison uses constant-time equality to prevent timing-based enumeration. |
|
Password-reset tokens are single-use and expire within a short, fixed window. |
Authorization & access control
| Exit condition | What it checks |
|---|---|
|
Every object access verifies the caller owns or is granted the specific record, preventing BOLA/IDOR across sequential identifiers. |
|
Administrative or privileged functions reject callers lacking the required role, preventing BFLA. |
|
Access control defaults to deny, so any route without an explicit grant is inaccessible. |
|
Authorization decisions are enforced server-side and never rely on client-supplied role or permission flags. |
|
Requests cannot read or write object properties the caller is not authorized for (mass-assignment / excessive data exposure). |
|
A user of one account cannot access or mutate resources belonging to a peer account at the same privilege tier. |
|
Role or permission changes cannot be self-granted through any request parameter or workflow. |
|
Direct navigation to hidden or unlinked privileged URLs is denied without a valid grant. |
|
Long-running or multi-step flows re-check authorization at each state transition rather than trusting the initial grant. |
|
Every Akka HTTP endpoint declares an explicit ACL and none inherit an unintended public default. |
Session & token handling
| Exit condition | What it checks |
|---|---|
|
Session cookies set |
|
Session identifiers are generated with a cryptographically secure random source of sufficient length. |
|
The session identifier is regenerated on login and privilege change to prevent fixation. |
|
Sessions expire after a bounded period of inactivity and after an absolute maximum lifetime. |
|
Logout invalidates the session server-side, not only by clearing the client cookie. |
|
JWTs are verified with a fixed expected algorithm, rejecting |
|
Token validation checks issuer, audience, and expiry claims before trusting any embedded identity. |
|
Akka endpoints requiring JWT reject tokens with a missing, expired, or untrusted signature before handler execution. |
|
Revoked or logged-out tokens are rejected before their natural expiry via a denylist or short lifetime plus refresh. |
|
Tokens carry no secrets or sensitive PII in their unencrypted payload. |
|
State-changing requests over cookie-based sessions require a validated anti-CSRF token or equivalent. |
Secrets management
| Exit condition | What it checks |
|---|---|
|
No API keys, passwords, or private keys appear as literals in source, config, or container images. |
|
Runtime secrets are loaded from a managed secret store or injected environment, not committed files. |
|
Secrets and tokens are redacted from application logs, error traces, and telemetry. |
|
Long-lived credentials support rotation without code changes and are rotated within policy intervals. |
|
Each service credential is scoped to the minimum permissions its workload requires. |
|
No secret is embedded in client-side bundles, mobile binaries, or responses sent to browsers. |
|
Secrets stored by the platform are encrypted at rest with managed keys. |
|
Repository history contains no previously committed live secrets detectable by a scanning pass. |
|
Provider keys follow the canonical |
Transport & at-rest encryption
| Exit condition | What it checks |
|---|---|
|
All external traffic is served over TLS and plaintext HTTP requests are redirected or refused. |
|
The service negotiates only TLS 1.2 or higher and disables deprecated protocol versions. |
|
Only modern cipher suites without known weaknesses are offered. |
|
Responses include a |
|
Outbound service-to-service calls validate certificates and do not disable verification. |
|
Sensitive data at rest is encrypted with a vetted algorithm and managed keys. |
|
No broken or deprecated primitives (MD5, SHA-1, DES, ECB mode) are used for security purposes. |
|
Security-sensitive random values use a cryptographically secure generator, not a predictable PRNG. |
|
Encryption keys are separated by purpose and environment, with no key reuse across tenants. |
|
Primary account numbers are masked in display and rendered unreadable in storage per PCI DSS. |
Input validation & injection
| Exit condition | What it checks |
|---|---|
|
Every request payload is validated against a strict schema for type, length, format, and range before processing. |
|
Database access uses parameterized queries or an ORM, never string-concatenated user input. |
|
NoSQL queries reject operator injection by validating and typing user-supplied filter values. |
|
User input never reaches shell or OS command execution without strict allowlisting. |
|
Directory queries escape or parameterize user input to prevent LDAP injection. |
|
User input is not evaluated inside server-side templates, preventing SSTI. |
|
File paths derived from input are canonicalized and confined to an allowed base directory. |
|
Request bodies, uploads, and fields enforce maximum size limits to bound resource use. |
|
Requests are rejected when their |
|
Input is normalized to a canonical encoding before validation to defeat double-encoding bypasses. |
Output encoding & response safety
| Exit condition | What it checks |
|---|---|
|
Dynamic values are context-encoded on output so user data cannot execute as script. |
|
Responses set a restrictive |
|
Responses include |
|
CORS allows only explicitly listed origins and never reflects arbitrary origins with credentials. |
|
Server-side fetches from user-supplied URLs are restricted by allowlist and blocked from internal/metadata addresses. |
|
Untrusted input is never deserialized into arbitrary object types that could trigger gadget chains. |
|
Error responses omit stack traces, internal paths, and framework version details. |
|
API responses return only fields the caller is authorized to see, with no leaked internal attributes. |
|
Redirect targets are validated against an allowlist to prevent open-redirect abuse. |
|
Framing of sensitive pages is prevented via frame-ancestors or |
Rate limiting & abuse prevention
| Exit condition | What it checks |
|---|---|
|
Each externally reachable endpoint enforces a per-client request-rate limit. |
|
Authentication and token endpoints apply stricter rate limits to slow credential-stuffing. |
|
Expensive operations enforce quotas to prevent resource-exhaustion denial of service. |
|
Throttled responses return 429 with retry metadata rather than failing opaquely. |
|
List endpoints cap page size so callers cannot request unbounded result sets. |
|
Agent invocations enforce a token or cost budget so a single request cannot exhaust model spend. |
|
Endpoints that reveal existence of records resist enumeration through rate limits and uniform responses. |
|
Uploaded files are type-verified and size-bounded before storage or processing. |
|
High-value unauthenticated actions require a challenge or proof-of-work under abusive load. |
Dependency & supply chain
| Exit condition | What it checks |
|---|---|
|
No dependency ships with an unresolved known-critical or high CVE at build time. |
|
Dependencies are pinned to exact versions or lockfiles so builds are reproducible. |
|
Fetched artifacts are verified against checksums or signatures before use. |
|
A software bill of materials is generated and available for the deployed artifact. |
|
Build artifacts carry SLSA provenance attesting to their source and build process. |
|
Container images are signed and their signatures verified before deployment. |
|
No security-relevant dependency is abandoned or past end-of-life without a remediation plan. |
|
All dependency licenses conform to policy, flagging incompatible or copyleft terms. |
|
Builds run in an isolated environment without inheriting developer credentials into artifacts. |
Logging, audit & privacy compliance
| Exit condition | What it checks |
|---|---|
|
Application logs redact or omit personal data such as emails, tokens, and payment details. |
|
Authentication, authorization, and privileged actions emit structured security-audit events. |
|
Audit records are tamper-evident and cannot be silently modified or deleted by application users. |
|
Every audited action records actor identity, timestamp, and source for accountability. |
|
Only personal data necessary for the stated purpose is collected and persisted (GDPR minimization). |
|
Personal data is deleted or anonymized once its retention period expires. |
|
A verified data-subject deletion request removes personal data across primary and derived stores. |
|
Data-subject access requests return the individual’s personal data in a portable format. |
|
Processing that requires consent proceeds only when a recorded, valid consent exists. |
|
Regulated data is stored and processed only within its permitted geographic regions. |
|
Cross-tenant queries are impossible, so one tenant’s data never surfaces in another tenant’s responses. |
|
Personal data held in entity state is classified and covered by encryption, retention, and erasure controls. |
|
Agent inputs and outputs pass guardrail checks that block prompt injection, data exfiltration, and disallowed content. |