Skip to content

Security_

How we handle your keys and data.

The concrete measures, not security theatre — every claim here is something the system actually does.

Report a vulnerability Privacy Policy

0

raw IPs stored_

0

card numbers accepted_

SHA-256

key & IP hashing_

Passkey / 2FA

required to sign in_

The measures_

Each of these is enforced in code.

Not a policy document — behaviours the system will not let you bypass.

01

API keys are stored only as hashes

A key's plaintext is shown exactly once, at creation. We store only its SHA-256 hash, so a database dump cannot mint working keys and we cannot recover a lost key for you — you rotate it.

02

IP addresses are hashed, never stored raw

Request logs record a salted SHA-256 hash of the caller's IP, not the address. We cannot reverse it, and the logs are pruned automatically.

03

Strong authentication is mandatory

Dashboard accounts require a passkey, or a password plus mandatory TOTP two-factor. Password-only accounts are not permitted.

04

Revocation is immediate

Revoking a key takes effect within the request, not after a cache window — the auth cache is evicted on every key change and on deletion.

05

Restrictions and webhooks fail closed

IP and domain restrictions refuse a request that does not match an allow rule. The billing webhook refuses to act unless its signing secret is configured, so a forged webhook cannot change your plan.

06

We never send your card numbers anywhere

The fraud endpoint accepts only a card BIN (the first 6–8 digits) and rejects anything longer at validation. A full card number cannot reach the API even by accident.

What we keep, what we don't_

The path a key and an IP take.

Two secrets pass through the system on every call. Neither is ever stored in a form we could hand back — here's exactly what happens to each.

  1. Key shown once

    The plaintext key is displayed a single time at creation. We keep only its SHA-256 hash.

  2. IP hashed at the edge

    The caller's IP is salted and hashed for logging and rate-limiting, never written raw.

  3. Revoke evicts instantly

    A revoked or rotated key clears the auth cache within the same request — no stale window.

  4. Card data rejected

    Send more than a 6–8 digit BIN and validation refuses it before it reaches any handler.

what-we-store.sh 
# what a stored record actually contains
{
  "key_hash":  "sha256:9f2a…c17b", # never the key
  "ip_hash":   "sha256:salted:4e0d…", # never the IP
  "bin":       "453201",          # 6–8 digits, max
  "card_number": null,        # rejected at validation
  "auth":      "passkey | totp",  # password-only refused
  "revoked":   true           # evicted this request
}
Responsible disclosure

Found something?

Please report it to our team — reports go straight to the people who can act on them. See also the Privacy Policy.

FAQs

Security questions

Does LocaleSense store the IP addresses I look up?

No. Request logs keep a salted hash of each address — enough to rate-limit and debug, never the raw IP — so lookups do not create a store of personal data.

Does the fraud check see full card numbers?

Never. The fraud endpoint accepts only the BIN — the first 6–8 digits that identify the issuer — and validation rejects anything long enough to be a full card number before it reaches the application.

How are API keys protected?

Keys are shown once at creation and stored only as a SHA-256 hash — nobody, including us, can read a key back. Keys can be restricted to domains, IPs or CIDR ranges (restrictions fail closed) and revocation takes effect immediately.

How do I report a security vulnerability?

Through the security contact on our contact page — reports go straight to the people who can act on them. Please include enough detail to reproduce the issue.