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:

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

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

What we have not built yet

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.