Security and privacy

Security model

The pilot uses application-owned authentication, active organization/project memberships, action capabilities and separate source-disclosure checks. The browser is not trusted to decide access. A hidden button is not a substitute for a server check.

Runtime data and compiled frontend assets are pinned and bounded. The API checks request methods, parameter allow-lists, origins for writes, body/response limits and rate budgets. The web page and API have content-security policies suited to their roles.

Identity and session limits

Pilot cookies are Secure, HttpOnly and SameSite=Strict. Password verification uses the application’s scrypt verifier implementation. The account registry is read at process startup; planned account changes must account for that reload boundary.

The Soldier Data pilot boundary is not an enterprise identity provider. It does not itself provide self-service registration/reset, MFA, a distributed login limiter or an immutable enterprise audit sink. Optional OIDC/identity-administration modules do not establish that those features are deployed.

Do not share accounts or paste cookies/tokens into API examples. Use separate authorized identities and the current membership policy. A view link never grants access.

Evidence and privacy handling

• County/tract measures describe geographic populations, not identifiable household or patient records. Do not infer an individual diagnosis or protected attribute from an area statistic.
• Project evidence, uploaded material and exports may contain restricted content even if underlying publishers provide public datasets. Share only through approved project and artifact workflows.
• Keep source attribution, scope and limitations with permitted use. Do not redistribute explore-only values through screenshots or ad hoc exports to bypass restrictions.
• Support reports should contain steps, time, safe project/subject identifiers and request IDs. Omit passwords, session cookies, signing material and private report contents.
• Do not assume browser memory is a durable store or that closing a tab revokes another active session. Use the approved session/account revocation procedure.

Deployment and secret boundaries

Production account documents and signing secrets stay outside the repository and public application image with operator-controlled ownership and permissions. Generic documentation commands use identifiers and placeholders, never secret values.

The M1/U3a runtimes are read-only directory mounts on the API. Revocation is a reviewed configuration operation with receipts; it is not a browser preference. The worker’s existing grants and artifact access remain separate.

Readiness/version endpoints are operator-scoped and publicly concealed. Do not expose them or relax CSP/authentication in order to make a smoke test easier.

Report a security issue

1. Stop attempting to reproduce an issue once you risk accessing another person’s data or changing production state.
2. Use your organization’s approved private channel to the application owner/operator. This repository does not establish a public security mailbox, bug-bounty program or response SLA.
3. Provide affected version, time, route/workflow, expected versus actual access, and a minimal redacted reproduction. Share sensitive evidence only through the operator-approved private mechanism.
4. The operator should preserve evidence, assess exposure, contain access and verify a fix through the affected authorization path. Communication and legal notification obligations require the organization’s applicable process.

Assurance boundaries

Passing automated tests and a production canary is evidence about those checks, not a security certification, penetration-test report, compliance determination or guarantee against all vulnerabilities.

Retention periods, backup encryption, incident notification terms, support hours and availability commitments must be established operationally. The documentation does not invent contractual commitments for them.