Security & data protection at B2B Database Network

Authentication and account security

Access starts at the login boundary. Accounts authenticate with a server-side session, and passwords are never stored in a form anyone can read them back from. We store a salted, slow password hash rather than the password itself, so even a full database read does not expose your credentials. Sessions are scoped, expire on a sensible schedule, and can be invalidated when you change your password or sign out.

We keep the user-facing surface and the administrative surface on separate authentication systems with separate session cookies, so an app session can never be promoted into an admin session. Bot and abuse protection sits in front of sign-up and sign-in to keep automated account creation and credential-stuffing attempts off the platform.

• Server-side sessions with secure, HTTP-only cookies and sensible expiry.
• Salted, slow password hashing — plaintext passwords are never stored.
• Separate auth domains for the app and the admin panel.
• Bot protection on registration and login to deter automated abuse.

API-key hashing and rotation

Your API key is the credential that lets code and AI agents act as you, so we treat it the way a good system treats a password. When you generate a key, the full value is shown exactly once. After that we keep only a one-way hash. We cannot recover or re-display the plaintext, and neither can anyone who reads the database, because the plaintext is simply not there to read.

Practically, that means you should store the key somewhere safe at creation time. If a key is ever exposed in a log, a repo, or a screenshot, the response is fast: revoke it from the dashboard and mint a new one. Revocation is immediate. You can also run more than one key, which makes rotation painless: create the new key, update your services, then revoke the old one with no downtime.

• Keys are displayed once, then stored only as a one-way hash.
• Instant revocation, with no waiting period.
• Multiple keys per account for clean, zero-downtime rotation.
• API spend draws from the same fair, never-expiring credit balance as the app.

Rate limits and abuse prevention

The API is rate-limited per key, with clear headers on every response so your code can back off gracefully instead of hammering a wall. Rate limits do two jobs. They keep the service fast and fair for everyone, and they put a ceiling on how quickly a single compromised key could be abused before you notice and revoke it.

Beyond simple request ceilings, we watch for patterns that do not look like normal use: sudden spikes, sequential enumeration, or traffic that suggests an attempt to mirror large slices of the database. Those patterns trigger throttling and review rather than silent success.

Export caps and honeytokens

A contact database has a specific risk that ordinary SaaS does not: someone paying for legitimate access trying to siphon the whole dataset for resale. We address it on two fronts. First, exports are subject to per-plan daily caps, so no single account can drain the database in an afternoon, and search results stay masked until you spend a credit to reveal them. Second, exports include seeded honeytoken records.

Honeytokens are synthetic, traceable records mixed into served data. They are harmless in normal use and never represent a real person. But if a list shows up somewhere it should not — resold on another platform, for instance — those markers let us identify the source. It is the data-product equivalent of a watermark, and it is one of the strongest deterrents against bulk redistribution.

• Per-plan daily export caps that throttle bulk extraction.
• Masked previews — emails are hidden until a credit is spent.
• Seeded honeytoken records that make redistribution traceable.
• Exports never include suppressed or opted-out records.

Suppression as a security and privacy control

Suppression sits at the intersection of privacy and security. When a person opts out through the Privacy Center, their email is hashed and added to a single permanent suppression list. That list is enforced in two places: when new data is ingested, so a suppressed contact is never re-added, and every time records are served, so they are never shown, exported, or returned through the API.

The important detail is that suppression overrides access. A fully authenticated, paying account with a valid API key still cannot retrieve a suppressed record. The control lives below the access layer, which is exactly where a privacy guarantee has to live to be real.

Encryption in transit

Every connection to the application, the REST API, and the MCP server is served over TLS. We do not accept plain-HTTP traffic for authenticated routes; requests are redirected to HTTPS, and HTTP Strict Transport Security tells browsers to use TLS on every future visit. Your credentials, your search payloads, and your exports always travel over an encrypted channel.

We also set a baseline of security response headers across the surface to reduce common web risks, and we keep the public marketing pages free of any individual's real contact details, so there is nothing sensitive to leak from a crawlable page in the first place.

The controls, at a glance

A summary of the protections described above and the risk each one addresses.

Responsible disclosure

We welcome reports from security researchers and treat them as a gift, not a threat. If you find a vulnerability, email security@b2bdatabase.net with a clear description and steps to reproduce. We will acknowledge your report promptly, keep you updated as we investigate, and credit you once a fix ships if you would like that.

The ground rules

• Give us a reasonable window to investigate and remediate before any public disclosure.
• Do not access, modify, or exfiltrate data that is not yours, and do not run tests that degrade the service for other users.
• Do not violate anyone's privacy. If you stumble onto personal data, stop and report it rather than collecting more.
• Act in good faith. We will not pursue legal action against researchers who follow these rules.

For data-removal and privacy-rights requests rather than security bugs, use the Privacy Center or email privacy@b2bdatabase.net.

Frequently asked questions