Security
Last updated 15 August 2026. Report something: info@capsakey.com
This page exists because the app it describes was built after a public failure of the alternative: in May 2026, a widely installed file-sharing app for websites showed one client's documents to another, and the complaint went unanswered. Everything below is a response to that.
The one design decision that matters
Isolation between two websites is not a filter. It is the address.
Each site gets its own database, addressed by the site's own instance identifier — and that identifier is only ever taken from a token the platform has validated for us. To read another site's data you would need a handle to another object, and nothing in the request path can produce one.
The common alternative is a shared database with a tenant identifier column, where separation depends on every query remembering to filter. That is a rule, and rules get forgotten. This is not a rule.
Inside a single site, separating one client from another is enforced by a table — so that case is attacked directly by an adversarial test suite that runs on every commit and blocks the merge if it fails. It opens by replaying the May 2026 leak.
How a file is served
- The portal asks our server for a ticket over an authenticated channel.
- The browser follows a URL carrying that ticket — necessary because a browser navigation cannot carry an authorisation header.
- The server verifies the ticket and then re-asks the database whether that member may still have that file, in one atomic step, before a single byte moves.
The ticket proves where the request came from. It never carries the right. So revoking access takes effect on the very next request — including the next range of a resumed download — rather than leaving a working link until it expires. Tickets last 60 seconds, and a valid ticket may be redeemed more than once inside that window, deliberately: a resumed download and a video player seeking both issue several range requests against the same URL. What bounds the exposure is not the count but the re-authorisation on each one.
Said precisely, because the loose version is tempting and wrong: a response already streaming runs to completion. Revocation does not sever an open connection. What it stops is everything after it. The worst case is that somebody finishes the one file they had already begun.
Note the contrast with the usual approach: a pre-signed storage URL is a bearer token — anyone holding it gets the file until it expires, no matter what has changed. We do not use one for downloads, which is also why download links stay on our own domain instead of a storage hostname.
Uploads
Bytes go from the browser straight to storage, over a URL signed for exactly one object, valid for 15 minutes. They never pass through our servers. Every signature is authorised first, and an upload belongs to the member who started it — another client of the same space cannot resume or complete it.
The stored size is read back from storage after the fact rather than trusted from the browser.
Access logging
Every download is recorded: which file, which member, when, how many bytes. The site owner can read their own log and no one else's, and export it as a spreadsheet.
Entries are kept for 12 months, and each one carries its own copy of the document and client names — so a line still reads as a sentence after the file it describes has been deleted, which is eleven months out of twelve.
Data at rest and in transit
- TLS everywhere; storage encrypted at rest.
- Files in Cloudflare R2, in a bucket restricted to the European Union at creation.
- Object keys are derived from identifiers, never from filenames, so a key discloses nothing.
- Deletion is immediate from view and complete within 30 days from storage.
What the portal does not do
No cookies. No localStorage, sessionStorage, IndexedDB or Cache API. No
third-party script, no analytics, no session recording. The portal holds nothing in the browser
between page loads, and the only thing it ever sends is a token the platform itself issued.
What we do not have
Said plainly, because a security page that claims everything is worth nothing:
- No virus scanning. A file is delivered as it was received. Do not treat an upload from a stranger as safe because it came through this app. On the roadmap, deliberately not in version one.
- The member's access token passes through the page. On a published site the platform hands it to a small script of ours embedded in the site, which passes it to the portal and removes it at once. Between those two moments another script on the same page could in principle take it, and would then reach that member's own files — the same files it could read off the portal rendered in front of it. This is how the platform authenticates a widget rather than a choice of ours; what is ours is the size of the window, and it is a single hand-over rather than the whole session.
- No SOC 2 or ISO 27001 certification. This is a small independent product; an audit at this stage would be a purchased badge rather than evidence.
- Cloudflare is a US company. The EU restriction governs where data sits, not who owns the company holding it. See sub-processors.
Reporting something
info@capsakey.com. We aim to acknowledge within one working day.
If you have found a way for one client to see another's files, say so plainly in the subject line and we will treat it as an incident immediately. We do not run a bug bounty, we will not threaten you, and we will credit you if you want to be credited.
Our own breach commitment: 24 hours to notify affected site owners and the platform. The procedure is written down in advance, not improvised.