--- title: Shared Security Requirements document_id: shared-security-requirements owner: Product Spec Maintainers status: draft created: 2026-03-16 last_updated: 2026-03-23 --- # Shared Security Requirements Feature specs should inherit these requirements unless an explicit exception is documented. Security sections in PRDs should list applicable requirement IDs from this document and note any justified exemptions, compensating controls, or feature-local additions. This document consolidates the current internal security review checklist and API security guidance into PRD-friendly shared requirements. Product surfaces may impose stricter controls than this baseline. ## How to Use - Reference applicable `SEC-###` IDs in PRDs, architecture docs, API contracts, and rollout plans. - Mark each requirement as applicable, not applicable with reason, or exception with compensating controls. - Document exceptions explicitly rather than silently omitting a shared requirement. - Add feature-local security requirements only when the feature introduces new exposure, trust boundaries, or control surfaces not covered here. - For internet-exposed interfaces or features that handle credentials, sensitive data, or privileged actions, include explicit scenario coverage for the relevant `SEC-###` IDs. ## SEC-001 Authenticated Access Requirement Statement: Administrative, control-plane, and protected data interfaces exposed by the feature must require authenticated access consistent with the product's supported identity model. Where the risk is materially higher, the feature should support stronger proof of identity such as certificate-based auth, step-up verification, or equivalent controls. Applicability Notes: Applies to APIs, CLIs, consoles, service-to-service calls, background services, and automation hooks that can change state or read protected data. ## SEC-002 Server-Side Authorization and Ownership Checks Requirement Statement: The feature must enforce authorization checks server-side for each action being performed, including tenant, role, resource-scope, and ownership boundaries where relevant. Requests must be evaluated against authoritative server state rather than trusting client-provided claims or front-end gating alone. Applicability Notes: Applies even when requests originate from trusted internal components, automation, or signed tokens. Multi-parameter workflows should validate the full combination of actor, target resource, and requested effect. ## SEC-003 Session and Token Lifecycle Hardening Requirement Statement: Sessions, cookies, API tokens, reset tokens, and other bearer credentials must have bounded lifetime, secure transport and storage properties, and explicit invalidation behavior on logout, timeout, password reset, or suspected compromise. Password recovery and similar flows must use verified, time-limited, single-use tokens. Applicability Notes: Applies to browser sessions, CLI login state, API tokens, service tokens, and recovery links or codes. Browser-delivered session material should use appropriate security attributes such as `HttpOnly`, `Secure`, and restrictive cross-site behavior where relevant. ## SEC-004 Least-Privilege Runtime and Credential Use Requirement Statement: The feature should operate with the minimum privileges needed for its documented behavior and must not require broad cluster, host, network, database, or cloud permissions without clear justification. Steady-state operation should use scoped, non-administrative credentials, and temporary credentials should be preferred where platform support exists. Applicability Notes: Particularly relevant for controllers, agents, replication services, database connections, cloud resource access, plugins, and automation components. ## SEC-005 Secrets and Key Management Requirement Statement: Secrets such as passwords, tokens, private keys, and connection credentials must be stored, transmitted, rotated, and revoked using approved secret-handling mechanisms rather than plain configuration patterns. Passwords must be stored as salted hashes, keys must not be hardcoded, and temporary sensitive material should be removed promptly from transient files or memory when no longer needed. Applicability Notes: Applies to both user-provided secrets and internally generated credentials. ## SEC-006 Transport and Cryptographic Protection Requirement Statement: Network communication carrying sensitive data, credentials, or privileged control traffic must support encryption in transit using approved TLS or equivalent secure transport mechanisms. Sensitive data stored at rest must use approved encryption and key-management controls when product policy requires persistence protection. Applicability Notes: Transport surfaces should support TLS 1.2 or stronger unless a stricter product standard applies. Internal service traffic should also be protected when it crosses trust boundaries or carries sensitive data. If a feature has no relevant network or storage surface, the PRD can mark this as not applicable. ## SEC-007 Secure Defaults and Surface Minimization Requirement Statement: Default configuration should minimize exposure by preferring safe access control, conservative network exposure, disabled high-risk capabilities, and restrictive cross-origin or ingress behavior unless explicitly enabled. Internet-exposed services should use approved edge protections for the product surface. Applicability Notes: Applies strongly to new endpoints, replication targets, extension hooks, and external integrations. Security-policy changes at the edge should be validated in non-production before rollout when the product surface supports staged testing. ## SEC-008 Input Validation and Injection Resistance Requirement Statement: Untrusted input must be validated and constrained server-side, using parameterized or precompiled queries for data stores and allowlist-based control of any invoked system commands or interpreters. Features must avoid designs that let raw user input directly shape privileged queries, file paths, shell execution, or similar sensitive operations. Applicability Notes: Applies to request parameters, uploaded content, background jobs, CLI arguments, connector configuration, and all paths that reach SQL, search, shell, or operating-system execution layers. ## SEC-009 Resource Limits and Automated Abuse Protection Requirement Statement: The feature must bound abusive or accidental request volume, payload size, concurrency, and automation where exposure warrants it. Sensitive flows should support rate limits, quotas, bot or device risk checks, human verification, or equivalent anti-automation controls when abuse risk is material. Applicability Notes: Especially relevant for login, password recovery, public APIs, resource-creation endpoints, user-uploaded content, and any operation that can amplify cost or degrade availability. ## SEC-010 Replay and Duplicate-Action Protection Requirement Statement: APIs or workflows that trigger costly, irreversible, or security-sensitive state changes must defend against replay or duplicate execution using nonce, timestamp, idempotency key, request signing, or equivalent freshness controls where appropriate. Applicability Notes: Relevant to provisioning, credential rotation, entitlement changes, destructive actions, payment-like operations, and externally callable create or mutate workflows. ## SEC-011 Sensitive Data Minimization and Masking Requirement Statement: The feature must minimize collection, retention, and exposure of sensitive data. Responses, UI surfaces, logs, traces, metrics labels, and exported artifacts must avoid unnecessary personal or secret data and should mask sensitive fields when display is required. Applicability Notes: When sensitive information must be visible for legitimate workflows, access should be limited to appropriately privileged roles and the display should remain traceable through supported audit surfaces. ## SEC-012 Safe Error Handling and Information Disclosure Control Requirement Statement: The feature must not reveal secrets, full credentials, raw private keys, stack traces, server fingerprints, internal file paths, or other attacker-useful implementation detail through errors, status surfaces, or debugging output. Authentication failures should avoid revealing which factor or identifier caused the denial unless product policy requires that distinction. Applicability Notes: When diagnostic value conflicts with disclosure control, prefer redaction, generic external errors, and richer detail only in protected operator-visible telemetry. ## SEC-013 Auditability of Security-Relevant Activity Requirement Statement: Privileged operations and security-relevant events must be captured in durable audit or operator-visible control records that identify the actor, timestamp, target, action, and outcome. Audit coverage should include successful and failed authentication, permission changes, security-configuration changes, sensitive data access, and invalid or expired session use where relevant. Applicability Notes: Retention duration should follow product or compliance policy. Audit records must still follow the masking and data-minimization requirements in `SEC-011`. ## SEC-014 Data Handling and Residency Awareness Requirement Statement: The feature must preserve documented data handling boundaries, including tenant isolation, residency constraints, and restrictions on where sensitive data or metadata may flow. Applicability Notes: Relevant to backup, replication, telemetry export, support tooling, managed-service workflows, and cross-region or cross-account integrations. ## SEC-015 High-Risk Action Integrity and Approval Requirement Statement: High-risk actions with financial, entitlement, destructive, or cross-tenant impact must be fully validated server-side against authoritative state and may require secondary approval, confirmation, or tighter rate limits before execution. Applicability Notes: Examples include quota grants, policy changes, destructive lifecycle actions, billing-affecting workflows, and other operations where a single incorrect request can create outsized impact. ## SEC-016 Dependency and Extension Safety Requirement Statement: Third-party dependencies, plugins, extension mechanisms, and external integrations introduced by the feature must not bypass core authentication, authorization, auditing, or data-handling controls and should be bounded by explicit trust, update, and capability assumptions. Applicability Notes: Applies to embedded libraries, runtime extensions, sink connectors, webhooks, SDKs, and user-supplied integration components.