Security

These are the practices we currently follow. They describe how the application is built and operated — not a certification claim.

Application and data

• All traffic is served over HTTPS with HSTS.
• Accounts use a managed authentication provider; passwords are never stored by us.
• Every user-owned table enforces row-level access rules in the database, so one account cannot read another's configurations, saved references, or license keys.
• Privileged operations are authorised server-side against a roles table; the browser is never trusted to assert a role.
• Secrets and third-party credentials live in managed secret storage, not in source code.

API keys

• License keys are stored as hashes; the full value is shown only once at creation.
• Validation uses a constant-time comparison, and revocation takes effect immediately.
• Keys are server-to-server credentials and must not be embedded in browser code.
• You can rotate or revoke a key at any time from your account.

Outbound fetching

The URL extractor only accepts http and https addresses, refuses private, loopback, link-local, and cloud-metadata addresses, caps redirects and response size, and times out. This prevents the feature from being used to reach internal systems.

Operations

• Structured logs with request identifiers for compile, library, license, and payment paths.
• Automated checks exercise the compile, library, and API paths and alert on failure.
• Third-party dependency failures degrade to a reduced experience rather than an error page.
• Current component state is published on the status page.

Reporting a vulnerability

Send details through the contact form with "security" in the message. We acknowledge within two business days, keep you informed while we investigate, and credit you if you would like that. Please avoid automated scanning that degrades the service for other users, and do not access data that is not yours.