Security

#How the API is built

• Read-only data. Data endpoints only read published, validated files. There is no endpoint that changes data, and no user content is stored besides key metadata.
• Runs at the edge on Cloudflare Workers, with HTTPS only (TLS 1.2+), HSTS and strict security headers on every response: Content-Security-Policy: default-src 'none', X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer.
• Keys are never stored. A key is generated from a cryptographically secure random source (about 238 bits), shown once, and stored only as an HMAC-SHA256 hash with a secret pepper kept outside the database. A database leak would not reveal usable keys.
• Secret keys cannot be used from browsers, and publishable keys only from their registered origins.
• Keys are never accepted in URLs, so they do not end up in logs or referrers.
• Abuse protection: per-minute rate limits at the edge, daily quotas, Cloudflare Turnstile on key creation, and limits per email and per network (IPv6 clients are grouped by prefix). Usage is counted in memory and written in batches, so heavy traffic cannot exhaust the database.
• Strict input validation: unknown parameters and fields are rejected; identifiers accept letters, digits and hyphens only; request bodies are limited to 4 KB and must be JSON. Database access uses parameterised statements only.
• Minimal data: for a key we store its name, the email you gave, an optional purpose, allowed origins, timestamps, and a keyed hash of the creating IP address (to enforce creation limits). Daily usage counters are deleted after 90 days.
• Supply chain: dependencies are pinned, CI actions are pinned to commit SHAs, and Dependabot proposes updates.

#Your responsibilities

• Keep secret keys on servers, in a secret manager or environment variables.
• Restrict publishable keys to the exact origins you use.
• Rotate keys when people leave your team or a key may have leaked.
• Validate and escape API data before inserting it into HTML in your own apps.

#Reporting a vulnerability

Email security@sentinara.org with a description, the affected URL, steps to reproduce and your contact. Please:

• Give us reasonable time to fix the issue before public disclosure (we aim to respond within 5 working days).
• Do not access other people's keys or data, degrade the service (no load or denial-of-service testing), or use social engineering.

We will not pursue good-faith research that follows these rules. Machine-readable contact: /.well-known/security.txt.