bluefield
Securitytrust

Security at Bluefield

Last updated June 2026

This page summarizes the controls that are implemented today, in plain language, and is deliberately explicit about what is not yet in place. Two principles run through the design: default-deny (new risk categories are added to the deny side, not allowlisted around) and validate, don't sanitize (bad input is rejected, never massaged and used anyway).

SSRF defense in two independent layers

Every URL that crosses into our platform — your scrape, crawl, map, batch, and webhook URLs, plus third-party search results — is validated before the request and re-validated at socket-connect time. The connect-time check defeats DNS rebinding, and redirects are re-checked per hop. Private, link-local, and cloud-metadata address ranges are blocked for both IPv4 and IPv6, failing closed on anything unparseable.

HTTPS-only, bounded egress

Outbound fetches are HTTPS-only; other protocols are rejected, not "fixed" and used anyway. Every outbound path has an explicit timeout, and the tier-0 fetcher caps response bodies (5 MiB default) to contain oversized or decompression-bomb pages.

API keys are hashed, never stored in plaintext

Keys are minted from a CSPRNG and stored only as a bcrypt hash (cost 12) alongside a short prefix — there is no plaintext key column. The full key is shown to you exactly once at creation and never logged. Verification is constant-time, so a wrong key and an internal error are indistinguishable by timing.

Constant-time secret handling

Every security-sensitive equality check uses a constant-time comparison with a length pad. Internal and admin gates fail closed: an unset secret returns 503 (never open), a wrong one returns 401. Our logger redacts tokens, key hashes, webhook secrets, and provider API keys before anything reaches a log sink.

Signed webhooks (HMAC-SHA256)

Outbound webhooks are signed Stripe-style over the exact wire bytes with a per-subscription secret and a timestamp, so you can verify authenticity and reject replays. Inbound Stripe webhooks are signature-verified against the raw body before any parsing.

Cryptographic attestation (Ed25519)

Every live fetch — one-shot /scrape and watch mode alike — returns a signed manifest over the content hash, canonical URL, fetch time, status, and a hash of the response headers. Verification resolves the key id against a pinned trust store — never the key embedded in the bundle — so a self-signed forgery is rejected. The production key is held in AWS KMS; when KMS is absent we persist an explicit "no-attestation" placeholder rather than a fake signature.

Web session & OAuth

Sign-in runs Google and GitHub OAuth with CSRF state and (for Google) PKCE, requiring a verified email. Session cookies are httpOnly, secure, and sameSite=lax; the session token is a pinned-algorithm JWT, blocking algorithm-downgrade attacks.

Public-surface-only crawling

We honor robots.txt as a hard block before any fetch runs, never authenticate to a target, and never bypass paywalls or anti-bot challenges by impersonation. Outbound user-agents are kept honest.

What we do not have yet

We would rather you hear this from us than discover it in a sales call. As of today:

  • We do not hold SOC 2, ISO 27001, or other third-party certifications today.
  • The managed API runs in the United States (Fly.io, us-east). We do not offer EU data residency on the default hosted tier — talk to us about enterprise options.
  • Cached responses and PDFs are not yet signed in v1 — live one-shot /scrape and watch-mode fetches are signed.
  • A published JWKS endpoint and a transparency log for attestation keys are planned, not shipped.
  • On the HTTP and unlocker proxy tiers, the manifest proxy_egress_ip field is a placeholder; the signature is genuine, but that one field is not yet truthful on those tiers.

Reporting a vulnerability

Email security@bluefields-data.com. Please do not open a public issue for an exploitable finding. We will acknowledge and work with you on a coordinated disclosure.

Related

See our sub-processors, data processing terms, service levels, and how to verify a signed capture.

This page describes our posture in good faith and is not a warranty or a contract. It is not legal advice.