Security by separation, least privilege and controlled release.

Identity and sessions

• Customer passwords are validated and hashed with scrypt using per-password random salt.
• Customer sessions use Secure, HttpOnly, SameSite=Lax __Host- cookies and have defined idle and absolute lifetime limits.
• The platform owner uses a separate identity boundary, a separate Strict SameSite session cookie and TOTP multi-factor authentication.
• Password reset and activation use one-time token workflows rather than exposing a permanent generated customer password.

Tenant and permission boundaries

• Role-based access controls determine what authenticated users can do.
• Tenant-owned database access is protected by PostgreSQL row-level security and transaction context.
• The normal application database role is not a superuser and is not configured to bypass row-level security.
• Platform-owner identity tables are separated from customer account/session tables.

Request and browser protections

• State-changing authenticated operations use CSRF/origin protections.
• Rate limiting is applied to sensitive public and authentication flows.
• Main HTML responses set Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and a restrictive Permissions-Policy.
• The managed public edge uses Caddy/TLS contracts and the API is designed to remain behind the managed web boundary.

Media handling

Uploaded media is placed into private S3 storage with public access blocked. The media pipeline accepts bytes rather than fetching arbitrary remote URLs, processes images, strips metadata through re-encoding, and serves approved variants through the application boundary.

Owner secrets and local access

The owner TOTP secret is encrypted by the application with AES-256-GCM using the configured owner TOTP key. The Windows Owner Access helper stores its local password cache through Windows DPAPI for the current Windows user. If that cache is missing or does not match the active owner account, the helper is designed to rotate the owner password, revoke active owner sessions, cache the new password with DPAPI and display the fresh local login details.

Billing integrity

Pricing and product-level combinations are locked by application and database contracts. Paid checkout is created only from the canonical Billing Core for the selected plan. Provider identifiers and verified webhook/reconciliation flows are used to maintain local subscription state.

Release controls

The project includes syntax, architecture, database, identity, provisioning, queue, AWS, domain/TLS, blueprint, content, media, assembly, product-closure, pricing, billing, web-smoke and secret-scanning checks. Release packages include a SHA-256 manifest that can be verified after extraction.

Responsible operation

Security is a shared operational responsibility. The operator must protect infrastructure credentials and provider accounts, keep supported runtimes patched, review logs and alerts, configure DNS/TLS and provider permissions correctly, and investigate suspicious activity. No application can promise zero risk.

Reporting

If you believe you found a security issue, do not exploit or access data beyond what is needed to demonstrate the issue. Send a concise report to serjomicoyan@gmail.com with the affected URL, reproduction steps and impact.