Security Overview

FileSafety is designed with security as a foundational requirement. Files are processed in isolated infrastructure, encrypted at every stage, and automatically deleted after scanning. This page provides an overview of the security model.

Architecture overview

Upload → Scan → Results → Auto-delete

Request flow

1. File submission — The client uploads a file via the API (direct upload or presigned URL). The file is stored in encrypted file storage.

2. Scan queuing — The file is queued for scanning.

3. Virus scanning — A dedicated virus scanning engine processes the file in an isolated compute environment with no public internet access.

4. NSFW scanning — A content analysis engine analyzes the file for explicit, suggestive, or violent content.

5. Result storage — Scan results (verdict, signatures, confidence scores) are written to the database. No file content is stored in the results — only metadata and the cryptographic hash.

6. Webhook delivery — The result is POSTed to the client’s webhook URL.

7. File deletion — The original file is automatically deleted from encrypted file storage after 24 hours.

Network isolation

Scan workers run in a private network with no internet gateway. All internal service communication happens through private endpoints.

This means scan workers cannot reach the public internet. Even if a scanned file contained a payload that attempted to phone home, the network configuration prevents any outbound connections.

Encryption

At rest

• All files in encrypted file storage are encrypted with AES-256
• Database tables use encryption at rest

In transit

• All API communication uses TLS 1.3
• Internal service communication uses encrypted channels
• Presigned URL uploads go directly to encrypted file storage over HTTPS

Data region

All infrastructure runs in Australia. Files, scan results, and metadata never leave this region. There is no cross-region replication.

API security

• Authentication via API keys (x-api-key header)
• API keys are hashed using a cryptographic hash before storage — the plaintext key is never stored
• Request validation and throttling on all API endpoints
• All endpoints require authentication; there are no public endpoints

File handling principles

1. Minimal retention — Files are deleted within 24 hours. Only the scan verdict and file hash are retained long-term.
2. No content logging — File contents are never written to application logs.
3. Quarantine isolation — Files are stored in dedicated encrypted file storage, separate from all other infrastructure.
4. Hash-only identification — After scanning, files are identified by their cryptographic hash, not by filename or path.

See also

• Data Handling — File lifecycle, encryption details, and what metadata is stored
• Compliance — GDPR readiness, SOC 2 notes, and DPA availability