Security and compliance
This page documents the security posture that is directly supported by the repository and current engineering docs.
Authentication model
SREDSimplify currently exposes two main authentication modes:
- bearer authentication for user and admin application APIs
- an internal token boundary for Java-to-Python worker calls
Public routes exist for authentication, pricing, contact submission, and Stripe webhook delivery, but the main application APIs require authenticated access.
Network and service boundaries
The browser does not call the backend origin directly. Requests route through the Next.js BFF, which forwards the request to the backend and keeps backend origin details and service credentials on the server side.
The Python worker is isolated behind an internal token boundary and is not intended as a browser-facing public API.
Stripe callbacks are separately protected through webhook signature verification.
Data and storage boundaries
The currently documented storage split is:
- PostgreSQL for application metadata
- Redis for auth-adjacent state, rate limits, and coordination
- object storage for uploaded file bytes
Only files that complete upload and indexing should be considered usable run context.
Secrets handling
Current repository guidance requires:
- no committed credentials or production secrets in git
- secret injection through managed environments such as Doppler or CI-managed secret stores
- redaction of secrets from logs, screenshots, and pull requests
Compliance posture
This repository documents security controls and boundaries, but it does not publish verified claims here for external frameworks or certifications such as SOC 2, ISO 27001, or GDPR attestation packages.
If compliance claims are later formalized, they should be added only after a reviewed source of truth exists.