Security and trust
This page describes controls that are implemented today. Where something is planned rather than built, it says so.
Your originals
The delivery pipeline issues only GET and HEAD against your origin. There is no write path in the data plane, no credential that would permit one, and no import or migration step. If you disconnect PicSoar tomorrow, your images are exactly where and how they were.
Why we are not an open proxy
The single most dangerous feature an image service can ship is a?url= parameter. It turns the service into a relay that anyone can point at anything, including hosts inside private networks that the attacker cannot reach directly.
We do not have one, and the architecture makes adding one difficult on purpose:
- The origin hostname comes from your project configuration, never from the request.
- You prove control of that hostname with a DNS TXT record before it is ever fetched.
- Hostnames that are IP literals, resolve to private, loopback, link-local, or cloud-metadata addresses, or end in a reserved suffix such as
.internalare refused at registration and re-checked at verification. - Redirects are followed only back to the same verified origin, over HTTPS, within your configured base path, for at most two hops.
- Only known image extensions are served, so the endpoint cannot be used to stream
.envor a database dump through our CDN.
Residual risk we will name rather than hide: DNS rebinding. The Workers runtime does not let us pin name resolution at fetch time, so a name that validated at verification and later resolves into private space is mitigated — by verification-time checks and periodic re-verification — rather than eliminated.
Credentials
- API keys are shown once, at creation. Only a SHA-256 hash is stored, and there is no code path that can recover a plaintext key — including for support.
- Keys carry explicit scopes and are bound to a single project, so a leak has a bounded blast radius.
- Keys can be expired, rotated, and revoked, and every one of those actions is an audit event.
- Session cookies are
HttpOnly,Secure,SameSite=Lax, and stored as hashes. - Cookie-authenticated mutations are origin-checked; API-key requests cannot be made ambiently by a browser.
Tenant isolation
Every tenant-owned table carries an organization column, and the data-access layer refuses at runtime to execute a query that does not bind the authenticated principal's organization. A resource belonging to another tenant reports 404, never 403 — a 403 would confirm the resource exists and turn identifier enumeration into a discovery tool.
Abuse and cost controls
- Public URLs name a preset; they cannot specify width, quality, or effects.
- Sources above 20 MB are passed through rather than decoded.
- Malformed requests are rejected before any network call, so an attack is cheap for us to refuse.
- Quotas are enforced server-side, in the API and at the edge, not only in the interface.
What we have not built yet
- Signed URLs are specified and implemented in code but not yet exposed as a product feature.
- SSO, SCIM, and audit exports are Enterprise items and are not available.
- We have not had an external penetration test. When we do, this page will say who and when.
- We hold no compliance certifications today and do not claim any.
Reporting a vulnerability
Email security@picsoar.com. We aim to acknowledge within two business days. Please do not test against other customers' projects.
Live availability is published at https://status.picsoar.com.