Compliance and reports
- SOC 2 Type II: Firecrawl is SOC 2 Type II compliant (renewal in progress).
- Trust Center: the Firecrawl Trust Center lists our compliance status and controls. You can request the latest penetration test and our Access Control, Data Management, Information Security (AUP), and Third-Party Management policies there.
- Continuous monitoring: the Trust Center monitors controls covering data encryption, penetration testing, continuity and disaster recovery plans, data retention procedures, and deletion of customer data when an account is closed.
Data handling and zero data retention
Zero Data Retention (ZDR) means Firecrawl does not persist page content or extracted data beyond the lifetime of the request or session. It is available on Enterprise plans and must be enabled for your team.
PII redaction can also remove personally identifiable information from scrape and parse output before it reaches you.
Contracts, DPA, and subprocessors
- DPA and custom contracts: Enterprise customers can sign a Data Processing Agreement and custom MSAs, and we support vendor security reviews and questionnaires.
- Subprocessors: the current list is published in the Trust Center. Subscribe there to get advance notice before a new subprocessor processes customer personal data.
- Privacy: see the Privacy Policy.
Identity and access control
- SSO and SCIM: SAML and OIDC single sign-on (Okta, Entra ID, Google Workspace, and more) and SCIM directory sync, so access follows your identity provider.
- Static IP allowlisting: route your traffic through dedicated IP addresses that you can allowlist on your systems.
- IP restrictions: limit your team’s API keys to an allowlist of IP addresses or CIDR ranges.
- Key restrictions: lock individual API keys to specific output formats and endpoints, enforced server-side.
- Spend limits: cap spending per API key or per team.
Network protections
Firecrawl only fetches public web addresses on your behalf. These protections run server side on Firecrawl Cloud for every plan, including Free, on every request Firecrawl makes to fetch a URL. They are on by default, and no request option turns them off.- Private and reserved addresses: Firecrawl’s HTTP fetcher refuses private (RFC 1918 and IPv6 unique local), loopback, link-local, and other reserved IP addresses, including the cloud metadata address
169.254.169.254andlocalhostnames, before anything is sent. Alternate encodings such as decimal, hex, or IPv4-mapped IPv6 forms are normalized first, so they are refused too. - Every redirect hop: the same check runs on the first request and again on each redirect, so a public URL can’t redirect a fetch into a private address.
- Egress outside our network: page fetches and browser sessions, including the page’s own subrequests, connect out through egress outside Firecrawl’s internal network. A hostname that resolves to a private address, including through DNS rebinding, is resolved and connected outside our infrastructure, so it can’t reach Firecrawl’s internal services or cloud metadata.
- Self-hosted Playwright service: when it connects directly, the open-source Playwright service resolves each hostname once, checks the answer, and connects only to the address it checked. This DNS rebinding fix (GHSA-xmmq-vp8j-m5qf, CVE-2026-116066) was merged on October 21, 2026 and ships in v2.11.586 and later. With an upstream proxy configured, that proxy must enforce its own egress policy. Firecrawl Cloud does not route requests through this service. If you self-host, run v2.11.586 or later and leave
ALLOW_LOCAL_WEBHOOKSunset, since setting it disables the private-address checks.
Monitoring and threat controls
- Threat Protection: block Firecrawl from fetching risky URLs, using a policy your organization controls and can lock.
- SIEM Audit Logging: stream a structured audit event for every scrape to your SIEM, starting with Microsoft Sentinel.
Data residency
Firecrawl processes all data in the United States and does not offer EU data residency. With zero data retention, the content you scrape or search is not stored after the request completes.For AI agent and MCP users
The same controls apply when Firecrawl is called from an AI agent, the MCP server, the CLI, or an SDK. IP and key restrictions, Threat Protection, and SIEM audit logging are enforced server-side for your organization, so a key restricted to certain endpoints or formats stays restricted whichever client uses it. Zero data retention applies to any request that enables it.FAQ
Is Firecrawl ready for an enterprise security review?
Is Firecrawl ready for an enterprise security review?
Yes. Firecrawl is SOC 2 Type II compliant (renewal in progress), offers zero data retention for scrape and interact plus two ZDR modes for search, signs DPAs, and supports SAML or OIDC SSO with SCIM. Server-side controls like IP and key restrictions, Threat Protection, and SIEM audit logging let your security team set and audit policy.
Is Firecrawl SOC 2 compliant?
Is Firecrawl SOC 2 compliant?
Yes. Firecrawl is SOC 2 Type II compliant, and our annual renewal audit is in progress. The Trust Center lists our current controls and policies.
Does Firecrawl offer zero data retention for search?
Does Firecrawl offer zero data retention for search?
Yes. End-to-end search ZDR (
enterprise: ["zdr"]) has both Firecrawl and our upstream search provider enforce zero data retention, so no query or result data is stored anywhere in the pipeline. See Search ZDR.Does Firecrawl block requests to private IP addresses and cloud metadata endpoints?
Does Firecrawl block requests to private IP addresses and cloud metadata endpoints?
Yes, on every plan and by default. Firecrawl’s fetcher refuses private, loopback, link-local, and reserved addresses, including
169.254.169.254, on the first request and every redirect hop, and all fetches connect out through egress outside Firecrawl’s internal network, so a DNS rebinding answer can’t reach our infrastructure. See Network protections.Will Firecrawl sign a DPA?
Will Firecrawl sign a DPA?
Yes. Enterprise customers can sign a Data Processing Agreement and custom MSAs. Processing happens in the US. Contact help@firecrawl.dev.
Where is data processed?
Where is data processed?
In the United States. Firecrawl offers US data residency and does not offer EU data residency.
Who are Firecrawl's subprocessors?
Who are Firecrawl's subprocessors?
The current list is in the Trust Center, with advance notice to subscribers before a new subprocessor processes customer personal data.
How do we start a security review?
How do we start a security review?
Request the latest penetration test and policies from the Trust Center, and email help@firecrawl.dev or use the Enterprise page for questionnaires and contracts.

