This page describes the security measures in place today. It changes when they do.
1. Where data is stored
- Customer data, including accounts, workspaces, screenings, monitoring, payments and checks, is stored in Cloudflare’s database (D1) and object storage (R2), created with European Union jurisdiction.
- The application runs on Cloudflare Workers. Our logs and background jobs carry identifiers and error codes, not names, email addresses or the identifiers of screened people.
- Sanctions lists are imported from official public sources and kept apart from customer data.
2. Sign-in and access
- Sign-in uses a one-time code sent by email; there are no passwords. The code is stored as a hash, is valid for 10 minutes and allows three attempts.
- A session lasts 12 hours. Its cookie is sent only over HTTPS, cannot be read by scripts on the page and is marked
SameSite=Lax, so browsers do not send it with requests that other sites make in the background or with their form submissions. Sessions do not record IP addresses or browsers. - Sign-in attempts and code requests are limited per IP address and per email address; the counters are kept under keyed hashes, not the addresses themselves.
- Cloudflare Turnstile protects the sign-in and public preview forms from bots.
- Every action in a workspace is checked against the member’s role in that workspace.
3. Data in transit and at rest
- All traffic uses HTTPS. The site sends HTTP Strict Transport Security for one year, a strict referrer policy, and a permissions policy that turns off the camera, microphone, location, payment and USB features.
- The sign-in page has a strict Content Security Policy; private pages are not cached and cannot be framed.
- Cloudflare encrypts all D1 and R2 data at rest with AES-256, under keys it manages.
- API keys are stored only as keyed hashes and are shown once, when created.
- Webhook signing secrets are encrypted (AES-GCM). Webhooks we send are signed (HMAC), go only to hosts approved for the workspace and do not follow redirects; an endpoint must answer a verification challenge before it receives events.
- Payment events from Stripe are accepted only with a valid signature made within the last five minutes.
4. Integrity
- Audit records, entity versions, review decisions, events and the credit ledger are append-only: the Service cannot change or delete them in normal operation.
- Operations that must happen once, such as charging a credit or adding credits for a payment, are protected against repetition and races: idempotency keys, leases and checks made in the same database statement as the change.
- The API allows 120 requests per minute per key; purchases and test alerts have their own limits.
5. How we build and change the Service
- Dependency versions are pinned and adopted only after they have been public for at least two weeks.
- Each development stage passes automated tests and an adversarial security review, with an independent second opinion, before it is deployed.
6. Reporting a vulnerability
Write to security@sanctionsradar.com with a description of the issue, how to reproduce it and its possible impact. Please do not access or change other people’s data, do not degrade the Service, and give us reasonable time to fix the issue before you disclose it. We confirm receipt within 5 business days, Monday to Friday except public holidays in Poland, and keep you informed. If you research in good faith, report what you find to us without undue delay, access or change no more data than you need to show the issue, cause no damage and use no social engineering, phishing or denial of service, we will not bring claims against you for that research, nor ask for you to be prosecuted for offences that are prosecuted only at the request of the injured party (Articles 267 and 268a of the Polish Criminal Code). This does not bind public prosecutors or third parties, and does not cover attacks on systems that are not ours.