DCAST Security
Last Updated: September 3, 2026
This page describes security measures that are in place on DCAST today. It is deliberately short. Everything below is something the platform actually does; where we have nothing to report, we say so rather than filling the space.
1. How creator content is stored
Videos uploaded to DCAST are packaged for delivery as HLS with AES-128 segment encryption. This is done by the processing pipeline for every upload — it is not a setting, a plan feature, or something a creator has to switch on. Each card is encrypted under its own key, generated once for the life of that card. Keys are not reused between cards and are not rotated afterwards, because rotating a key would leave already-published segments undecryptable for viewers who are watching.
The key is not part of the media. A player has to ask for it in a separate request. For any card that is not fully public, that request must carry a valid, unexpired playback pass issued for that specific card — without one it is refused, and an encrypted segment on its own is not playable.
2. Access levels
Every video carries exactly one access state, and it is that state — not the obscurity of the link — that decides who may watch:
- Public — anyone may watch.
- Unlisted — reachable with the direct link, not listed in search or on the platform.
- Registration required — the viewer completes a short form the creator defines before playback begins.
- Subscribers — a signed-in viewer who subscribes to the creator.
- Tier — a signed-in viewer holding the specific tier the creator selected.
- Private — the owner only.
A creator can also sell access to a card, as a one-off purchase or through an access code. Live broadcasts use their own set of states: public, link only, registration required, private, and a passphrase the creator sets.
Two properties are enforced in code rather than left to convention. An access value the platform does not recognise is refused — it is never quietly stored as the most open state, which is what a "sensible default" would amount to on a privacy setting. And the states are treated as a set of requirements rather than a ranking, so a change between two of them cannot be mistaken for a loosening when it is in fact a tightening.
3. Playback passes and withdrawing access
Playback passes are issued per card, are time-limited, and are validated on the request that uses them rather than once at the start of a session.
Passes can also be withdrawn before they expire. Withdrawal can be applied to a single purchase, a single payment, an access code, one buyer's access to one card, one playback session, an entire live broadcast, or an entire video. When a creator tightens a card — for example from public to private, to subscribers-only, or behind a payment — the passes already issued for that card are withdrawn at the same time, so access closing does not have to wait out the passes that were handed out before it.
Ownership is checked on every playback request. A card that is private to its owner is refused to everyone else, signed in or not.
4. Accounts and sign-in
Sign-in runs through Keycloak, a dedicated identity server, and tokens are verified against its published signing keys. Where DCAST holds a password hash itself, it is Argon2id; administrator accounts use bcrypt at cost 12.
Two-factor authentication (TOTP) is available on accounts. With it enabled, a correct password alone does not produce a session — the second factor is required before any token is issued. Backup codes are stored hashed, never in the clear.
You can end sessions from your account: one session, all other sessions, or every session at once. Ending a session takes effect for tokens that were already issued to it.
Authentication endpoints are rate limited — sign-in and other authentication requests to 10 per 15 minutes per client, account creation to 8 per hour — and the counters are shared across all backend processes rather than counted separately by each.
Administrative actions are written to an audit log recording who acted, what action was taken, which resource was affected, the source address, the user agent, and whether it succeeded.
5. Connections and browsers
The public sites are served over HTTPS and send HTTP Strict Transport Security (one year, including subdomains). Pages are returned with X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that limits camera and microphone to our own origin and disables geolocation.
Cross-origin access to the API is restricted to an allowlist of our own domains. The public partner API is a deliberate exception — it exists to be called from integrators' own sites, and its embed player is designed to load cross-origin.
6. Payments
Card details are entered on the payment provider's own form. DCAST does not receive or store card numbers; what we keep is the provider's own reference to a payment, which is what lets us match a purchase to the access it granted.
7. Reporting a security problem
If you believe you have found a vulnerability, report it through our contact form and choose the Security vulnerability topic, so the report is routed for triage rather than queued as a general enquiry. Please include enough detail for us to reproduce the issue.
We ask that you give us a reasonable opportunity to address a report before making it public, and that your testing does not involve other people's accounts or content, does not degrade the service for other users, and does not access data that is not yours.
8. What this page does not claim
We would rather say less than claim more than we can support. This page makes no assertion about certifications or compliance audits, and DCAST does not currently run a paid vulnerability reward programme or publish a target response time for security reports. If you are evaluating DCAST commercially and need assurances beyond what is written here, write to us and we will answer your specific question rather than point you at a badge.
Contact: [email protected] · Privacy Policy · Terms of Service