Security

Files from strangers, treated as such

A file-processing API accepts hostile input by definition. Somebody will eventually upload a PDF crafted for a parser vulnerability, and the honest engineering assumption is that one day one of them will work.

The design assumes the parser loses

Most of the security work here is not spent preventing that. It is spent making it worthless: the process that gets exploited has no network to exfiltrate over, no credentials to escalate with, and no access to any file but the one it was given.

Parsers get no network

Processing runs in private subnets with no NAT gateway and no internet route. A parser that is exploited has nowhere to call home to, which turns most remote-code-execution chains into a crash.

Parsers get no credentials

A processing task holds no IAM permissions on your data. It receives short-lived URLs scoped to one object and one operation, injected for that job. There is no key to steal because there is no key.

One container per file

Every job runs in its own task with its own microVM boundary and is destroyed afterwards. Nothing is reused between files, so nothing carries between customers.

Tenant comes from the credential

Your organisation is derived from the verified API key or session, never from a field in the request. A client that sends someone else’s organisation id is ignored, not obeyed.

Keys are never stored readable

API keys are verified against a keyed hash whose secret lives in a managed secret store, separate from the database. A database disclosure does not yield usable keys.

Uploads land in quarantine

An uploaded file is not addressable content until it has been validated. Buckets have public access blocked at the account level and are encrypted with managed keys.

What we do not claim

No compliance badges

Fylane is not HIPAA, PCI or FedRAMP certified, and is not SOC 2 audited. Those are programmes with their own controls, auditors and cost — not a page you write. We will say we have them on the day we have them, and not one day earlier. If your use case requires one of them today, Fylane is not the right choice today.

We are also a small team, and pretending otherwise would be its own kind of security problem. What we can offer is that the design decisions are written down and the reasoning is public.

Reporting a vulnerability

Send it to security@fylane.dev (opens in a new tab). We will confirm receipt, tell you what we found, and credit you if you want the credit. We will not threaten you, and we will not ask you to sign anything before we fix it.