Security & Infrastructure
How we keep your files safe
Files never touch our servers
PutPut uses presigned URLs for all uploads. Your files go directly from your client to Cloudflare R2 storage — they never pass through our API servers. We generate a signed upload URL, you PUT the file directly to R2, then confirm the upload. Our servers never see your file contents.
Built on Cloudflare
Every layer of PutPut runs on Cloudflare's global network:
- Cloudflare R2 — Object storage with zero egress fees. Files are replicated for durability.
- Cloudflare Workers — Edge compute in 300+ locations worldwide. Sub-100ms API responses globally.
- Cloudflare D1 — SQLite at the edge for account and file metadata.
- Cloudflare CDN — Files served from the nearest edge node to the requester.
Encrypted everywhere
Your data is protected both in motion and at rest:
- In transit — All API and upload traffic uses HTTPS/TLS. No plaintext connections.
- At rest — R2 encrypts all stored objects with AES-256 by default.
Zero cold starts
PutPut runs on Cloudflare Workers, not traditional serverless functions like AWS Lambda. There are no cold starts — your API requests execute immediately on the nearest edge node. This means consistently fast responses regardless of traffic patterns.
Token security
API tokens are handled with care:
- SHA-256 hashed — Tokens are hashed before storage. We never store plain-text tokens in the database.
- Scoped permissions — Each token is tied to a specific account with defined limits.
- Shown once — The raw token is returned only at creation time. If lost, generate a new one.
SVG sanitization
Uploaded SVG files are stripped of embedded scripts, event handlers, and other XSS vectors before being stored. This prevents malicious SVGs from executing JavaScript when served to browsers.
Magic byte verification
When you declare a content type for an upload, PutPut verifies the actual file headers (magic bytes) match the declared type. This prevents content-type spoofing — you cannot upload an executable disguised as an image.
Open source
The PutPut SDK and CLI are open source. You can inspect every line of code that runs on your machine. The client libraries make standard HTTPS requests — no hidden telemetry, no phone-home behavior.
Responsible disclosure
Found a vulnerability? Email security@putput.io. We ask that you give us 90 days to address the issue before public disclosure. We do not currently offer a bug bounty, but we will credit reporters in our changelog.
Architecture Trust Model
Your files never touch our servers
PutPut is designed so your file bytes never pass through our application servers. Here is exactly how the three-step upload flow works:
- Presign — Your client calls
POST /api/v1/upload/presign. Our API generates a time-limited, single-use presigned URL pointing directly at Cloudflare R2 storage. - Upload — Your client PUTs the file directly to R2 using that presigned URL. The file bytes travel from your machine to Cloudflare's storage network. Our API server is not in the data path.
- Confirm — Your client calls
POST /api/v1/upload/confirm. Our API verifies the file exists in R2, records metadata in the database, and returns the public CDN URL.
The SDK source code is fully readable — you can trace every network request to verify this flow yourself.
OWASP API Security Top 10
Honest self-assessment against the 2023 edition
API1 — Broken Object Level Authorization
Mitigated. Tokens are scoped to their own files. Every API request verifies the token owns the requested resource server-side. You cannot access another token's files.
API2 — Broken Authentication
Mitigated. Tokens are cryptographically generated, SHA-256 hashed before storage, and transmitted only over HTTPS. Guest tokens are bearer tokens with defined scopes.
API3 — Broken Object Property Level Authorization
Mitigated. API responses return only the fields relevant to the authenticated token. File metadata is scoped to the owning account. No mass-assignment vulnerabilities — inputs are explicitly validated.
API4 — Unrestricted Resource Consumption
Mitigated. Rate limiting enforced on token creation and API endpoints. Guest tokens are limited to 1 GB storage, 100 MB max file size, and restricted content types. Free accounts have 10 GB storage and 250 MB file size caps. Pro plans include 50 GB storage with metered overage at $0.10/GB. All plans enforce per-request rate limits.
API5 — Broken Function Level Authorization
Mitigated. No admin endpoints exist in the public API. All authenticated endpoints require a valid token. Unauthenticated endpoints (guest token creation, claim) are rate-limited.
API6 — Unrestricted Access to Sensitive Business Flows
Mitigated. The claim flow uses a cryptographic secret. Guest token creation is rate-limited. Upload requires a valid presigned URL that is time-limited and single-use.
API7 — Server Side Request Forgery (SSRF)
Mitigated. The API does not fetch user-supplied URLs. Presigned URLs point only to our R2 bucket. No proxy or redirect endpoints exist.
API8 — Security Misconfiguration
Mitigated. CORS is configured for API routes. Error responses do not leak stack traces or internal details. TLS is enforced everywhere via Cloudflare. No debug endpoints in production.
API9 — Improper Inventory Management
Mitigated. All API routes are documented at docs.putput.io. Legacy /api/* paths are 308-redirected to /api/v1/*. No shadow or undocumented endpoints.
API10 — Unsafe Consumption of APIs
Mitigated. PutPut does not consume third-party APIs at runtime. R2 access uses aws4fetch with signed requests. No user-supplied data is forwarded to external services.
Compliance Roadmap
Infrastructure certifications and planned milestones
PutPut runs entirely on Cloudflare's infrastructure, which maintains ISO 27001, SOC 2 Type II, and PCI DSS certifications. This gives us a strong compliance foundation from day one.
Current Controls
- Encryption at rest — AES-256 via Cloudflare R2
- Encryption in transit — TLS on all connections, enforced by Cloudflare
- Token hashing — SHA-256 before storage, plain-text tokens never persisted
- Zero telemetry — No analytics or tracking in the SDK or CLI
- SVG sanitization — Script and event handler stripping on upload
- Content-type verification — Magic byte checks prevent MIME spoofing
- Rate limiting — Enforced on token creation and auth endpoints
SOC 2 Timeline
- SOC 2 Type I — Targeted for mid-2026. Point-in-time assessment of security controls.
- SOC 2 Type II — Targeted for early 2027. Ongoing audit of controls over a 6-12 month observation period.
Cloudflare's existing certifications cover the infrastructure layer. Our SOC 2 efforts will focus on application-level controls, access management, and operational procedures.