Quick answer: SpiderFoot data is as secure as the machine you run it on. The open-source version stores every scan in a local, unencrypted SQLite database, and the web UI has no login by default. It does not send your results to the SpiderFoot developers, but its modules do send your targets to third-party APIs. To keep scans secure: bind the UI to 127.0.0.1, enable authentication or use an SSH tunnel, encrypt the disk, protect API keys, and delete old scans.
SpiderFoot collects a lot of sensitive information: leaked credentials, employee emails, internal hostnames, IP ranges and sometimes personal data. If that database leaks, it becomes a ready-made attack map. This guide explains exactly where SpiderFoot data goes, the real risks, and a practical checklist to secure it in 2026.
Where Does SpiderFoot Store Your Data?
| Data | Where it lives | Protected by default? |
|---|---|---|
| Scan results and logs | SQLite database (spiderfoot.db) in SpiderFoot’s data folder, for example ~/.spiderfoot on Linux | No encryption |
| API keys and settings | Same database | No encryption |
| Exports (CSV, JSON, GEXF) | Wherever you save them | No |
| Web UI traffic | HTTP on port 5001 | No TLS by default |
| Queries to data sources | Sent to third-party APIs over the internet | Usually HTTPS, but the provider sees your target |
With Docker, the database lives inside the container unless you mount a volume. Anyone with access to the host can usually read it.
Does SpiderFoot Send Your Data Anywhere?
The open-source SpiderFoot runs locally and does not upload your scan results to its developers. However, it is an OSINT tool, so modules must send your target (a domain, IP, email and so on) to external services like VirusTotal, Shodan or search engines to get answers. Those providers may log your queries under their own privacy policies.
Tip: For sensitive investigations, review which modules you enable, and read the privacy policy of each API provider. Our SpiderFoot modules and data sources guide lists what each one does.
The Main Security Risks
- Exposed web UI. Starting SpiderFoot with
-l 0.0.0.0:5001on a public server without authentication lets anyone view your scans and launch new ones. - Unencrypted database. A stolen laptop or compromised server reveals every scan and API key.
- API key theft. Keys stored in settings can be abused, running up bills or burning your quota.
- Plain HTTP. Without TLS, traffic on a shared network can be intercepted.
- Over-collection. “All” scans collect far more personal data than you may need, increasing legal risk.
- Untrusted forks or instances. Modified code or someone else’s server can leak your targets.
SpiderFoot Security Checklist
1. Keep the web UI private
python3 sf.py -l 127.0.0.1:5001Binding to 127.0.0.1 means only your own machine can connect. For remote servers, use an SSH tunnel:
ssh -L 5001:127.0.0.1:5001 user@your-server2. Turn on authentication
SpiderFoot supports HTTP digest authentication through a passwd file in its data folder. Each line holds a username:password pair. Restart SpiderFoot after creating it. For team or internet access, also place it behind a reverse proxy (Nginx or Caddy) with HTTPS.
3. Add HTTPS
Use a reverse proxy with a Let’s Encrypt certificate, or SpiderFoot’s own TLS options, so logins and results are encrypted in transit.
4. Encrypt the disk
Use BitLocker (Windows), FileVault (macOS) or LUKS (Linux) on any machine that stores SpiderFoot data. This protects the database if the device is lost or stolen.
5. Lock down file permissions
chmod 700 ~/.spiderfoot
chmod 600 ~/.spiderfoot/spiderfoot.dbRun SpiderFoot as a normal user, not root.
6. Protect your API keys
- Create separate keys just for SpiderFoot.
- Set usage limits or alerts with each provider where possible.
- Rotate keys if a machine may be compromised.
7. Collect less, delete more
- Use Passive or targeted modules instead of “All” when you can.
- Delete old scans from the Scans page when they are no longer needed.
- Store exports in encrypted folders and remove them after the engagement.
8. Use official code and keep it updated
Install from the official GitHub repository or your distribution’s package (such as Kali’s). Keep the OS, Python packages and Docker images patched. Never enter targets into unknown public SpiderFoot instances; see our SpiderFoot online guide for safe hosting.
Secure Setup by Scenario
| Scenario | Recommended setup |
|---|---|
| Personal laptop | Bind to 127.0.0.1, full-disk encryption, delete old scans |
| Kali VM for pentests | Separate VM per client, encrypted disk, wipe or archive after the job |
| Cloud VPS | Docker bound to 127.0.0.1, SSH tunnel or HTTPS proxy with auth, firewall, SSH keys |
| Team use | Reverse proxy with HTTPS and per-user logins, access logs, retention policy |
| Android (Termux) | Localhost only, screen lock, delete scans after use |
Setup guides: Windows, Mac, Linux and Docker, Kali Linux and Termux.
Legal and Compliance Considerations
Scan results may include personal data such as names, emails and phone numbers. If you operate under GDPR or similar laws, you need a lawful basis, should collect only what is necessary, keep data secure and delete it when no longer needed. In penetration tests, your contract should state how OSINT data is stored and destroyed. See how SpiderFoot is used responsibly in offensive and defensive security.
This article is general information, not legal advice.
Frequently Asked Questions
Is SpiderFoot safe to use?
Yes, the official open-source SpiderFoot is widely used and its code is public. The main risks come from how you run it: an exposed web UI, an unencrypted database or leaked API keys. Follow the checklist in this guide to stay safe.
Does SpiderFoot encrypt scan data?
No. The open-source version stores results and settings in a local SQLite database without encryption. Use full-disk encryption and strict file permissions to protect it.
Does SpiderFoot have a login page?
Not by default. You can enable HTTP digest authentication by creating a passwd file in SpiderFoot’s data folder, and add a reverse proxy with HTTPS for stronger protection.
Do third parties see my SpiderFoot targets?
Yes. Modules send your target to external APIs such as threat-intel services and search engines. Those providers may log queries, so choose modules carefully for sensitive work.
Where is the SpiderFoot database stored?
By default in SpiderFoot’s data folder, such as ~/.spiderfoot on Linux, in a file named spiderfoot.db. In Docker it sits inside the container unless you mount a volume.
How do I delete SpiderFoot scan data?
Delete scans from the Scans page in the web interface, remove any exported files, and delete the spiderfoot.db file if you want to remove everything.
Conclusion
SpiderFoot does not leak your data on its own, but it does not protect it much either. The database is unencrypted, the web UI has no login by default, and your targets are shared with the data sources you enable. Keep the UI on localhost or behind authentication and HTTPS, encrypt the disk, protect your API keys and delete what you no longer need. Do that, and SpiderFoot is safe to use for serious investigations.
Next, learn which targets SpiderFoot can analyze.
Pingback: SpiderFoot Web UI vs CLI: Key Differences (2026 Guide)
Pingback: SpiderFoot Modules & Data Sources: 2026 List + API Keys