How CRWLR Handles Your Data

Your firewall config contains the keys to your network. We know that. Here is exactly what happens when you upload one.

What We Read

We parse your config to extract network structure only — the minimum needed to identify security gaps. Nothing else.

✓Firewall policies — source/destination zones and addresses, services, action, logging, schedule
✓Zones, interfaces, and IP assignments
✓NAT rules and address translation mappings
✓VPN tunnel config — remote gateway, IKE version, encryption algorithms, DH groups, SA lifetimes
✓Security profile assignments — IPS, AV, web filter, SSL inspection profile names
✓Admin usernames, roles, trusted host restrictions, 2FA status
✓Certificate metadata — subject, issuer, key type, expiry status
✓Device identity — hostname, serial number, model, firmware version
✓Routing topology — static routes, BGP/OSPF neighbor IPs (not auth credentials)
✓HA cluster config — mode, priority, heartbeat interfaces

What We Never Touch

These fields exist in your config file. We never extract, store, or process them:

Passwords & hashes	Skipped entirely. FortiGate ENC blocks, PAN-OS phash elements, Sophos admin credentials — the parser ignores all of them.
VPN pre-shared keys	We record that PSK auth is in use. The actual key value is never read from the config.
RADIUS / LDAP secrets	We note the server exists and whether TLS is enabled. Shared secrets and bind passwords stay in your config.
SNMP community strings	Community label names are noted. The actual shared secret string is never extracted.
BGP / routing passwords	We record whether a neighbor password is set (true/false). The password itself is discarded.
Private keys & PEM data	Certificate subject and issuer are read. No private key material or certificate bodies are parsed.
API tokens & keys	Not extracted from any vendor format.

This is an architecture decision, not a policy. Our parser data types have no fields for secrets. There is nowhere to store them even if someone tried.

Config File Lifecycle

Upload

Your file is sent directly to the scan engine. It is held in memory only — never written to disk or cloud storage.

Scan

We parse the structure in memory, run security checks, and save findings. The normalized policy structure (zones, IPs, rules) and security findings are stored — no secrets, no raw file. IPs are obfuscated by default.

Disposal

The raw config file is discarded from memory immediately after parsing. There is no retention setting because there is nothing to retain — the file never reaches storage.

This is an architecture decision. Our scan pipeline has no code path to persist raw config files. A SHA-256 hash of the original file is stored for audit verification.

What We Store

For transparency: while raw config files and secrets are never stored, the following network data IS retained in our database to power your security analysis:

IP addresses & subnets	Source and destination addresses from firewall policies are stored in scan findings and the normalized policy structure.
Zone names	Network zone labels (e.g. "lan", "wan", "dmz") are stored to map traffic flow and assess segmentation.
Hostnames & serials	Device hostname and serial number are stored to identify and track firewalls across scans.
Policy rules	The full policy structure (source, destination, service, action, logging) is stored for analysis.
Firmware version	Stored to match against known CVEs and recommend safe upgrade targets.

IP Address Privacy (on by default)

All IP addresses are automatically replaced with anonymous placeholders (Host-A, Net-1) before findings are saved. You can disable obfuscation in Account → Security if you need real addresses in your reports. This is irreversible per scan — obfuscated data cannot be recovered.

Tenant Isolation

Every database query includes your account ID as a mandatory filter. Your data cannot appear in another customer's dashboard, API response, or background job.

✓Database — Row Level Security policies on every table
✓API — JWT verification scopes every request to your account
✓Storage — File paths include your account ID, validated on every operation
✓Background jobs — Alerts, scans, and cleanup run per-tenant, never cross boundaries

Encryption

✓In transit — TLS on all connections: API, dashboard, storage, webhooks
✓At rest — AES-256 encryption on database and storage
✓Encrypted backups — Sophos encrypted configs are decrypted in memory during the scan, never written to disk unencrypted. The password is not stored.

What Shows Up in Reports

Findings include enough context to act on them:

✓Policy name, source/destination zones, addresses, services
✓What is wrong and why it matters
✓Vendor-specific CLI commands to fix it
✓CIS benchmark references where applicable

If you enable IP obfuscation in account settings, traffic-related IP addresses are replaced with synthetic addresses. Policy structure remains readable — you need that to fix things.

Access Controls

✓10+ character passwords with complexity requirements and common password blocklist
✓Email verification required on signup
✓Short-lived JWT sessions with automatic expiry
✓Rate limiting on all endpoints, with stricter limits on auth routes
✓Generic error messages on login and signup to prevent account enumeration

Scan Isolation

Every scan runs in an isolated worker thread with hard resource limits. A malformed or malicious config cannot affect other customers or crash the platform.

✓Sandboxed worker threads with 512 MB memory cap and 5-minute timeout
✓XML configs pre-scanned for excessive nesting depth before parsing
✓Concurrent scan limits enforced globally and per-account
✓Worker crash marks the scan as failed — no impact on other operations

Infrastructure

Hosting	Render (US)
Database & Storage	Supabase (AWS us-east-1)
Analytics	None — no third-party tracking scripts
AI Summaries	Anthropic Claude API — your data is sent in a single request and not used for model training
CI/CD	Automated dependency audits, secret scanning, and type checking on every deploy

Need specifics for a vendor security questionnaire or compliance review?

Reach out at security@crwlr.io — we answer directly.