Security Overview

The shape of the thing

The most useful security property of this product is architectural: your screenshots are rendered, encoded and zipped inside your own browser. They are never uploaded, never processed on a server, and never sit in a queue somewhere waiting to be picked up. What reaches us is your project document and the source captures you chose to store so you can pick the work up on another machine.

That removes an entire class of exposure rather than defending against it.

Accounts and sessions

Passwords are stored only as salted hashes, using the password hashing built into our authentication library. We cannot read your password, and neither can anyone who reaches the database.

Sessions live in a cookie that JavaScript cannot read, is restricted to this site, and is marked secure so it travels only over HTTPS. Resetting a password ends every open session on the account.

Sign-in, sign-up and password reset endpoints are rate limited per address, so guessing at a password is slow enough to be useless.

Confirming your email address is required before an account can create its first app.

One account cannot see another

Every query that reads or writes private data filters by the account that owns the row, and all of them live in a single module that builds the SQL — a check performed earlier in a route does not count as protection there. That module is covered by tests written specifically to fail if a query loses its owner filter, because a leak between accounts is the worst thing this product could do.

The identifiers in URLs are validated before they reach the database, and a request for an app that is not yours is answered the same way as a request for one that does not exist.

Uploads

A capture or font you upload is checked before it is stored, and not by trusting what the browser said it was:

• The file type is decided by reading its leading bytes, not its name or its declared content type.
• Image dimensions are read from the file itself, so a client cannot misreport them.
• Every route has a declared ceiling on the body it will accept, checked before a single byte is read, and a write that arrives from another site is refused before that.
• Stored files are served back only to their owner, with the headers that stop a browser from ever treating one as a script or a document: no sniffing, a restrictive content policy, and same-origin resource policy.

The pages themselves

Every HTML response carries a content security policy with a nonce generated for that response. Scripts run only if they carry that nonce, which means an injected script does not run, rather than running and being noticed later.

On the production site: HTTPS with strict transport security, framing denied outright, a referrer policy that does not leak paths to other sites, and a permissions policy that switches off the camera, the microphone, geolocation and USB, and allows the payment API only for the checkout.

Payments

We never see a card. The checkout is served by Paddle inside their own frame, and the transaction is created by our server so that the price cannot be chosen by the browser.

Payment notifications from Paddle are verified against their signature over the exact bytes received before anything is applied, and each event is recorded so a repeat delivery cannot apply twice.

The infrastructure

The application, the database and the uploaded files run on servers we operate at DigitalOcean. The database is not exposed to the internet, secrets are supplied by the environment rather than built into the image, and the application refuses to start if one is missing, so a half-configured deployment fails loudly instead of running with the payment webhook unverified.

Database schema changes are an explicit, deliberate step of a deployment rather than something that happens on start-up.

Uploaded files live on the application’s own disk, reachable by the application, by us, and by the provider that operates the machine — which is what the sub-processors page is for; we do not add a second layer of per-file encryption on top of the platform. If your compliance needs encryption at rest under a key you hold, ask before you buy rather than after.

What we do not have

Stated plainly, because the absence of a claim is easy to miss: there is no SOC 2 report, no ISO 27001 certificate, no penetration test report to share, and no 24/7 on-call rota. This is a small independent product, and its honest security story is the narrow attack surface and the specific decisions above, not a badge.

If something goes wrong

If a breach affects your personal data, we will tell you by email without undue delay and notify the relevant supervisory authority within 72 hours where the law requires it. The message will say what happened, what data was involved, what we have done, and what you should do.

Reporting a vulnerability

Email support@easyappscreens.com with "Security" in the subject. We aim to acknowledge within 3 business days and to tell you what we found and when it is fixed.

If you report a vulnerability in good faith, give us reasonable time to fix it, do not access or modify data belonging to anyone else, and do not degrade the service, we will not pursue you for the research. There is no cash bounty; there is credit on this page if you want it.