Free100Leads

Security

Last updated 19 August 2026

What we do not hold

Most breach reports you read are about card numbers. We hold none. Payment pages are hosted by Stripe and card details go from your browser to them without passing through us, so there is no card data here to lose, which is worth more than any control we would gain by handling it ourselves.

Passwords are stored as scrypt hashes with a per-account salt, never as anything reversible, and we cannot tell you your own password because we do not know it. Session identifiers are stored hashed too, so a copy of the database is not a set of live sessions. API keys are the same: only a SHA-256 of the secret half is kept, which is why a lost key can be replaced but never recovered.

We store no full IP address. Addresses are truncated to the network block before anything is written down.

How the service is built

• No unauthenticated API over the leads. Nothing on this domain returns contact records as JSON to a caller without a key. The paid API lives on its own hostname, requires a key tied to a subscription, is metered and rate limited per key, and has no way to ask for a record by its identifier, so it cannot be walked in parallel the way an offset or an id would allow.
• Signed, server side identifiers. The visitor cookie is HTTP only and carries a signature, so it cannot be edited to mint a fresh allowance.
• Single use request tokens. Each batch needs a token that is spent on use, which stops a captured request being replayed.
• Wheel outcomes decided on the server. The browser only animates to the result. Nothing about the prize can be changed from the client.
• Layered rate limits. Per visitor, per network block, and one ceiling across the whole site each day, so a determined scraper cannot turn a slow leak into a fast one.
• Traceable markers. Every full batch carries a marker unique to that visitor and day, and records delivered to a paid key carry one tied to the key and the billing period. If a list appears in someone else's product, we can prove where it came from.
• A ramp on new subscriptions. A brand new paid account reaches its full daily ceiling over a week rather than immediately, which removes the value in subscribing, taking as much as possible and charging back.

Where it runs

Dedicated hardware in Germany, operated by Hetzner. Cloudflare terminates TLS and filters traffic in front of the origin. Databases are not reachable from the public internet, and administrative access is by key only.

Reporting a vulnerability

Send it through the contact form. Include what you found and how to reproduce it. You will get a human reply, and a fix or a timeline within thirty days.

Report in good faith and we will not pursue you, whatever else the terms say. Good faith means testing against your own visitor session, stopping at proof rather than pushing on, never touching data belonging to other people, and giving us a chance to fix it before you publish.

Please leave out denial of service testing, physical attacks, social engineering of anyone at the company, and anything that degrades the service for other visitors. We do not run a paid bounty, and we will credit you if you want the credit.

If something goes wrong

If a breach puts anyone's data at risk, we notify the relevant supervisory authority within 72 hours of becoming aware, and we tell the affected people directly where the law requires it. We would post it on this page too.

Honest limits

Worth saying plainly, since most security pages will not. Anonymous rate limiting is best effort by design. Someone determined, with residential proxies and enough patience, can collect more than their share. The layers above are built to make that slow and expensive rather than impossible, and the site wide daily ceiling caps what any single day can lose.

The contact data itself is public information, so the risk in a leak is different from a password breach. That is not a reason to be careless with it, and the privacy notice sets out what we hold and why.