Security

Reporting a vulnerability

Write to bilgi@basvurukarnesi.com with the affected URL or endpoint, the steps to reproduce, and what you were able to observe. We aim to acknowledge within three working days. Machine-readable contact details are published at /.well-known/security.txt per RFC 9116.

Please do not run automated scans that degrade the service for others, do not access or modify data that is not yours, and give us a reasonable window before public disclosure. There is no paid bounty programme; we will credit reporters who ask to be credited.

Controls in place

• HTTPS everywhere, with HSTS and TLS terminated at the edge.
• Security response headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options and Cross-Origin-Opener-Policy.
• Row Level Security on every database table. The public corpus is readable; billing, payment, webhook, entitlement-change and API-usage tables have RLS enabled with no policy at all, so they are reachable only by the service role.
• The browser never talks to the database directly. It talks to a documented API layer, which is the only thing holding privileged credentials.
• No card data is ever stored. Payment execution is delegated to a payment provider; the application database is the source of truth only for entitlement state.
• No cookies, no third-party scripts, and therefore no third-party data flows to inventory.

Known limits

This is an early-stage product. Authentication and payment flows are designed but not yet enabled, so no user credentials are stored at present. The corpus is public by design — the security boundary protects integrity and the commercial layer, not the documents.