Security

The backend accepts one thing: a token whose issuer, audience, signature, lifetime, and required claims validate through OIDC and JWT Bearer. Provider-specific login and session behavior belongs to a frontend or an extension, because the API cannot recheck a login flow it cannot see. An unsigned token, an unvalidated decode, or a client-supplied identity header is never accepted: each one lets a caller mint its own identity.

Reviewed forThe backend authentication setup validates issuer, audience, signature, lifetime, and required claims, with no identity header accepted.

Marked guidance: a reviewer answers this question.

Actor resolution has one home: the WebApi boundary, which maps verified claims to identity, roles, and scopes through the one current-actor accessor. Request data never supplies the current actor, because anything the caller sends can name anyone. One resolution path keeps every operation answering "who acts" from the same verified source.

Reviewed forActor resolution in WebApi maps verified claims through the one current-actor accessor.

Marked guidance: a reviewer answers this question.

One decision from one declaration stops two operations about the same record from asking different questions. The use case declares the permissions it needs, the guard resolves the actor's roles at the target's scope, and the decision follows. A message whose target must be the caller carries no target (litespec/core/access#remove-a-target-that-must-be-the-caller). A handler never compares the caller with a target and never throws the forbidden refusal itself; the guard decides. Endpoints add only coarse policies, because a policy that cannot see business data cannot decide about an aggregate.

Reviewed forEach protected operation passes the application guard from its use case's declared permissions.

Marked guidance: a reviewer answers this question.

A collection has no single target, so the check that litespec/quality/security#authorize-each-target-resource states has nothing to resolve against: the scope must become part of the database query itself. Reading the unrestricted set already exposes the rows to the process, and a page assembled from them leaks the total count even when every row is dropped. Filtering after the load is the shape OWASP lists as broken object level authorization.

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.

Reviewed forEach protected collection query carries its authorization scope as a database predicate before paging.

Marked guidance: a reviewer answers this question.

Message shape, required values, length, range, format, and pagination bounds stay with the application validators that litespec/backend/application#separate-input-validation-from-invariants names, and business invariants stay with Domain. Each layer then answers only the questions it can see. Database content, provider responses, file contents, and generated text stay untrusted when they cross into a new output context, because validation for one context proves nothing about the next.

Reviewed forEach trust boundary validates transport shape and file metadata before use.

Marked guidance: a reviewer answers this question.

Every place a secret lands is a place it leaks from: source reaches every clone, logs and traces reach every dashboard reader, URLs reach every proxy log, snapshots and container layers outlive the process, and browser storage reaches the user. Platform secret stores hold the values instead, and diagnostics redact sensitive configuration before it is emitted, so the value never enters the observable stream.

Reviewed forSource, logs, traces, messages, files, URLs, snapshots, layers, and browser storage hold no secret.

Marked guidance: a reviewer answers this question.

String concatenation or interpolation into raw command text makes the value part of the statement, so a crafted value rewrites the query. A provider query API or a parameterized SQL parameter keeps the value as data. 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.

Reviewed forEach external value reaches the database through a query API call or a SQL parameter.

Marked guidance: a reviewer answers this question.

The error contract has one home: the HTTP API rules. Every public error then carries the same stable shape with nothing extra. A stack trace, SQL, connection detail, provider body, uncontracted internal identifier, or authorization reason that reveals resource existence gives an attacker the system's structure with every error.

Reviewed forEach public error carries the HTTP API error contract shape.

Marked guidance: a reviewer answers this question.

The browser is hostile ground: injected scripts, forged requests, malicious redirects, and hostile markup all arrive as ordinary page content. Framework escaping, a documented Content Security Policy, secure headers, redirect validation, forgery protection, and sanitization of allowed rich content each blocks one of those attacks. A route guard or hidden control is presentation, so it never replaces API authorization.

Reviewed forEach frontend ships framework escaping, a Content Security Policy, secure headers, redirect validation, forgery protection, and rich-content sanitization.

Marked guidance: a reviewer answers this question.

Data the use case never collects cannot leak from it. Collecting, returning, logging, exporting, and retaining only the declared fields keeps each use case's exposure exactly what its page promises. A use case handling sensitive data states its classification, access, retention, deletion, and audit behavior on its page, so the promise is written where the fields are.

Reviewed forEach use case collects, returns, logs, exports, and retains only its declared fields.

Marked guidance: a reviewer answers this question.

Export, erasure, and breach answers each ask the same opening question: which stores hold this person's data, which fields, for which purposes, and for how long. An inventory the team can read answers it in one place. Without it, each request starts with a search across logs, indexes, and outboxes, and the store nobody remembers stays out of the answer.

Reviewed forThe inventory names the fields, purposes, and retention of each store holding personal data.

Marked guidance: a reviewer answers this question.

Personal data lives in logs, search indexes, and outboxes beside the database. A request honored in the database but left in a log export answers half the duty and breaks the promise to the person. A backup cannot answer field by field, so it carries a retention bound instead, and the data ages out with the backup.

Reviewed forErasure and export reach every store on the inventory, with backups expiring inside their bound.

Marked guidance: a reviewer answers this question.

Logs flow to stores the product does not control: collectors, dashboards, long-term archives. Redaction at the sink fails once, in one pipeline, and the cleartext is already downstream. A field never emitted fails nowhere.

Reviewed forLogs, traces, and diagnostic records carry no personal data in clear.

Marked guidance: a reviewer answers this question.

A digest without a salt reverses by table lookup: anyone holding a table of common values recovers the original. It hides nothing, so it gets none of the relaxed handling a truly one-way value earns. The same handling as the data itself keeps the digest from leaking what the data would.

Reviewed forEach unsalted digest of personal data receives the handling its source data receives.

Marked guidance: a reviewer answers this question.

A breach deadline starts running at discovery. The applicable constraint record states the deadline the outside rule sets. A deadline with nobody named to meet it slips past the team, and one named person fails on the first absence. Naming both before anything happens keeps the procedure starting on time.

Reviewed forThe breach procedure names the person who acts, a backup person, and the deadline the constraint record states.

Marked guidance: a reviewer answers this question.

Live data at rest outlives the process: disks, snapshots, and replicas each hold a copy outside the application's control. Encryption keeps each copy unreadable without its key. Where encryption does not apply yet, the exception covering this provision keeps the gap visible with its reason, exit, and expiry date instead of silent.

Reviewed forEach live store carries encryption, or an exception record covers this provision.

Marked guidance: a reviewer answers this question.

Public, authentication, webhook, search, and upload endpoints invite abuse: credential stuffing, scraping, flooding. Declaring the bound as a setting record names the key that isolates one caller and the rejection response the caller sees. The rejection is 429 with a stable code, so legitimate callers can back off and retry.

Reviewed forEach public, authentication, webhook, search, and upload endpoint declares its setting with key and rejection response.

Marked guidance: a reviewer answers this question.

A per-process counter multiplies the declared limit by the replica count, so the limit the specification states is not the limit the system applies. The multiplier also changes whenever the deployment scales, which makes the effective limit unstated and unreviewable. One store every replica reads keeps the applied limit equal to the declared one.

Reviewed forThe deployment reads rate and concurrency counters from one store on every replica.

Marked guidance: a reviewer answers this question.

A wildcard origin lets any site call the API with the user's credentials, which turns every malicious page into an API client. Listing allowed origins, methods, headers, and credential mode keeps each cross-origin caller explicit. 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.

Reviewed forThe cross-origin policy lists origins, methods, headers, and credential mode with no wildcard origin.

Marked guidance: a reviewer answers this question.

An incident review reconstructs who did what to which target, with what outcome and why. Without actor, action, target, outcome, timestamp, trace identifier, and reason on each security event, the reconstruction is guesswork. 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, which states a wider field set, a classification rule, and a tamper-evidence rule.

Reviewed forEach security audit event records actor, action, target, outcome, timestamp, trace identifier, and reason.

Marked guidance: a reviewer answers this question.

Every secret leaks eventually: through a departing teammate, a copied file, an old backup. A secret-inventory entry with storage location and next rotation date keeps each secret's lifetime bounded, and 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, and revocation and recovery live in a runbook.

Reviewed forEach production secret carries a secret-inventory entry with location and rotation date beside its revocation runbook.

Marked guidance: a reviewer answers this question.

ASVS 5.0 defines three levels, L1, L2, and L3, with each requirement verifiable to pass or fail, and the organization picks one by risk. The level lives on a quality requirement with its measure, as litespec/core/intent#state-the-measure-on-a-counted-requirement states, so the target is checked rather than declared. The level choice and any accepted finding are each decided once by a person.

Reviewed forThe security quality requirement names its ASVS level with a passing check.

Marked guidance: a reviewer answers this question.

The ZAP baseline runs the spider with passive scanning and no active attacks, so it is safe on every pull request, with a WARN, FAIL, and IGNORE config file. Its JSON report feeds the model with the other measured results, and the scan passes with no medium or high alert. ZAP is free and maintained under Apache-2.0.

Reviewed forThe ZAP result file under TestResults/ shows no medium or high alert for the pull request.

Marked guidance: a reviewer answers this question.

CodeQL is free only on public repositories, where no paid plan is required; on a private repository the project uses a free alternative and records the choice in its CI documentation. An accepted finding lives as a gap exception covering the finding, with its reason, exit, and expiry date, so each acceptance stays visible and dated.

Reviewed forThe static analysis report for the pull request shows its findings with a gap exception for each accepted one.

Marked guidance: a reviewer answers this question.