Security

Requirement A backend MUST validate issuer, audience, signature, lifetime, and required claims through OIDC and JWT Bearer.

Rationale Provider-specific login and session behavior belongs to a frontend or an extension. An unsigned token, an unvalidated decode, or a client-supplied identity header is never accepted.

Requirement Actor resolution MUST follow litespec/quality/security#use-one-current-actor-abstraction.

Rationale Actor resolution has one owner: the WebApi boundary. Request data never supplies the current actor.

Requirement The application guard MUST authorize every protected operation from its use case's declared permissions, as litespec/backend/application#enforce-target-authorization-in-the-pipeline states, with endpoints adding only coarse policies.

Rationale One decision from one declaration stops operations about the same record asking different questions. An actor holds a role at a scope, a role allows permissions, and a use case needs permissions.

Requirement A protected collection query MUST apply its authorization scope as a database predicate, before paging, rather than filter a materialized result.

Rationale A collection has no single target, so the check that litespec/quality/security#authorize-each-target-resource states has nothing to resolve against. Reading the unrestricted set already exposed the rows to the process. A page assembled from them leaks the total count even when every row is dropped. OWASP lists this as broken object level authorization.

Example A query for an organization's orders adds the organization predicate to the database query. It does not load every order and drop the ones the caller may not read.

Requirement A trust boundary MUST validate transport shape and file metadata before use, leaving message checks to application validators as litespec/backend/application#separate-input-validation-from-invariants states.

Rationale Message shape, required values, length, range, format, and pagination bounds are the validator checks litespec/backend/application#separate-input-validation-from-invariants names. Domain validates business invariants separately. Database content, provider responses, file contents, and generated text stay untrusted when they cross into a new output context.

Requirement A secret MUST NOT appear in source, logs, traces, exception messages, generated files, URLs, snapshots, container layers, or browser storage.

Rationale Platform secret stores hold the values and diagnostics redact sensitive configuration before it is emitted.

Requirement An external value reaching the database MUST travel through a provider query API or a parameterized SQL parameter.

Rationale String concatenation or interpolation into raw command text makes the value part of the statement. The provider query API is Marten's under the baseline and EF Core's under its extension, and both parameterize. The reporting extension owns the reviewed raw SQL patterns.

Requirement A public error MUST use the error contract litespec/backend/api#return-stable-problem-details defines.

Rationale The error contract has one owner: the HTTP API rules. A stack trace, SQL, connection detail, provider body, uncontracted internal identifier, or authorization reason that reveals resource existence gives an attacker structure.

Requirement A frontend MUST apply framework escaping, a documented Content Security Policy, secure headers, redirect validation, forgery protection, and sanitization of approved rich content.

Rationale A route guard or hidden control is presentation, so it never replaces API authorization.

Requirement A use case MUST collect, return, log, export, and retain only the fields its input and results declare.

Rationale A use case handling sensitive data states its classification, access, retention, deletion, and audit behavior on its page.

Requirement A platform holding personal data MUST keep a personal-data inventory per store naming the fields, purposes, and retention of each store.

Rationale An inventory the team can read is the map every export, erasure, and breach answer starts from.

Requirement Erasure and export MUST reach every store holding personal data, with backups expiring inside the retention bound the Limit records state.

Rationale Stores include logs, search indexes, and outboxes beside the database. A request the team honors in the database but leaves in a log export answers half the duty. A backup cannot answer field by field, so it carries a retention bound instead.

Requirement A log, trace, or diagnostic record MUST NOT carry personal data in clear.

Rationale Redaction at the sink fails once, while a field never emitted fails nowhere.

Requirement An unsalted digest of personal data MUST receive the same handling as the data itself.

Rationale A digest without a salt reverses by table lookup, so it hides nothing from anyone holding the table.

Requirement A breach-notification procedure MUST name an owner and a backup person and meet the deadline the applicable Constraint record states.

Rationale A deadline nobody owns slips past the team, and an owner without a backup fails on the first absence.

Requirement Live data at rest MUST carry encryption or an Exception record naming this rule.

Rationale Encryption is the default, and the Exception keeps the gap visible with its reason and review date.

Requirement A public, authentication, webhook, search, or upload endpoint MUST declare its limit as a Limit record with key, owner, and rejection response.

Rationale The key limits one caller, the owner monitors the limit, and the rejection response is 429 with a stable code.

Requirement A deployment running more than one replica MUST hold its rate and concurrency counters in one store that every replica reads.

Rationale A per-process counter multiplies the declared limit by the replica count, so the limit a specification states is not the limit the system applies. The multiplier also changes when the deployment scales, which makes the effective limit unstated.

Requirement A cross-origin policy MUST list its allowed origins, methods, headers, and credential mode without using a wildcard origin.

Rationale Validated configuration owns the allowlist, so an unlisted origin cannot arrive by mistake. Deployment-owned origins are allowed when the allowlist shape is validated at startup.

Requirement A security audit event MUST record actor, action, target, outcome, timestamp, trace identifier, and available reason.

Rationale Audit records follow a documented retention and access policy, exclude secrets, and stay available for incident review. A consumer that activates the audit extension records the event through that extension instead. The extension states a wider field set, a classification rule, and a tamper-evidence rule.

Requirement A production secret MUST have a secret-inventory entry naming its owner, storage location, and next rotation date, with revocation and recovery in a runbook.

Rationale Rotation allows overlap while clients switch. Procedures, logs, artifacts, and audit records carry no secret value, as litespec/quality/security#keep-secrets-out-of-tracked-and-observable-data states.