FAST-VID uses an anonymous session rather than an account login. The session associates jobs and file links with the current browser. A separate short-lived token authorizes the completed file request for a particular job and session.
This article explains session cookies, CSRF protection and file tokens. It does not claim that these controls provide complete security or that links can be shared safely.
What a browser session is
A session lets a server recognize the same browser across multiple requests without asking for a username and password each time. The browser holds a session identifier, and the server keeps associated state such as jobs and expiry.
FAST-VID's session is anonymous: it does not require an account. That reduces account data, but it does not make the session public. Anyone who obtains a valid session cookie may be able to act within that session until it expires.
A session cookie is not a download token. The cookie associates requests with the browser session; a separate file token authorizes access to one completed file.
Cookie flags in plain language
HttpOnly prevents page JavaScript from reading the cookie. Secure restricts transmission to HTTPS apart from limited localhost behavior. SameSite=Lax limits many cross-site requests while allowing top-level navigation.
Path=/ makes the cookie available across the site's paths. The __Host- prefix adds browser-enforced requirements: Secure, Path=/ and no Domain attribute. FAST-VID uses this prefix in the production configuration inspected.
These flags reduce specific risks. They do not make a stolen cookie harmless, prevent every cross-site attack or guarantee that the server is trustworthy.
CSRF protection is separate from authentication
Cross-site request forgery tricks a browser into sending a request the user did not intend. A valid session cookie does not prove that the request came from the site's own page.
FAST-VID derives a CSRF token from the stored session-token hash and returns it through the API. The page sends it in the X-CSRF-Token header. It is not stored as a separate CSRF cookie. The server also checks origin and Fetch metadata where available.
CSRF protection is not the same as session authentication and not the same as a file token. It protects state-changing requests from being forged; it does not grant file access by itself.
Why file tokens are short-lived and scoped
A file token authorizes a narrow action: retrieve a completed file for a specific job and session, for either download or preview. The token is stored hashed, checked against its purpose and rejected after expiry.
Short lifetimes reduce the window in which a leaked link is useful. Job and session binding prevent a token from being reused for another file or browser session. Purpose separation prevents a preview token from being used as a download token or vice versa.
FAST-VID's current defaults are 300 seconds for download tokens and 1,200 seconds for preview tokens. Both are configurable. The exact lifetime can change, so do not treat these values as a permanent promise.
| Mechanism | Primary job | Typical lifetime |
|---|---|---|
| Session cookie | Associate requests with a browser session | Configurable; default 24 hours in this codebase |
| CSRF token | Prove a state-changing request came from the site | Session-derived; sent in a request header |
| Download token | Authorize one completed-file download | Short-lived; default 300 seconds |
| Preview token | Authorize one MP4 preview | Short-lived; default 1,200 seconds |
Why tokens and sessions should not be shared
Posting a file token in a public chat or support ticket can give others access during its remaining lifetime. Posting a session cookie can expose much more: it may allow access to every job associated with that browser session until expiry.
Do not paste cookies or tokens into screenshots, issue trackers, analytics tools or third-party websites. If a token is exposed, the safe action is to let it expire or request a fresh workflow, not to edit or extend it.
FAST-VID does not treat a download link as a permanent public URL. It is a temporary authorization for the current workflow.
What FAST-VID implements
In the inspected production configuration, the anonymous session cookie is named __Host-ydl_session, uses HttpOnly, Secure, SameSite=Lax, Path=/ and no Domain attribute. The session lifetime is configurable and defaults to 24 hours.
The raw session token is not stored; a hash is stored. Activity updates last_seen but does not extend the stored expiry. CSRF is header-based, origin and Fetch checks are applied where available, and file tokens are job- and session-bound.
The inspected access-log configuration redacts the X-CSRF-Token, Authorization, Cookie and Set-Cookie header values and the token, preview_token and download_token query values. Other request metadata may still be logged. This is a useful control, not a claim of zero logging, complete anonymity or immunity to every attack.
Limits of the design
Short-lived, scoped tokens reduce exposure, but they do not stop a compromised browser, a malicious extension, a shared device or a user who deliberately exposes a token. HTTPS protects the connection, but the endpoint and the device still matter.
Session expiry and token expiry are different clocks. A file token can expire before the session, and a session can expire before a job is complete. Do not assume that one lifetime covers the other.
The strongest practical rule is simple: keep the browser session private, use a trusted device and network, and treat download links as temporary credentials rather than public URLs.
A practical session checklist
Use a trusted browser and device, keep the session cookie private, and request a fresh file link when you need one. Do not paste cookies or download URLs into support messages or public posts.
After using a shared computer, sign out where the service offers it and clear site data if appropriate. If you suspect a session or token was exposed, treat it as a security issue and use a fresh session rather than trying to repair the old link. A session and a file token can also expire on different schedules.
Frequently asked questions
Is a session cookie the same as a download token?
No. A session cookie associates requests with a browser session. A download token authorizes a specific completed-file request for a job and session.
What does HttpOnly do?
It prevents page JavaScript from reading the cookie. It does not prevent the browser from sending it or make a stolen session harmless.
Why use both CSRF protection and file tokens?
CSRF protects state-changing requests from forgery; file tokens authorize a narrow file request. They address different threats.
Can I share a FAST-VID download link?
It is a temporary authorization, not a public sharing link. Anyone with it during its lifetime may be able to use it. Keep it private.
Does FAST-VID guarantee complete security?
No. It uses scoped sessions, CSRF checks and short-lived tokens, but no design guarantees complete security against every compromised device or attacker.
Sources and references
- MDN: Using HTTP cookies
- MDN: Set-Cookie header
- OWASP: Session Management Cheat Sheet
- OWASP: CSRF Prevention Cheat Sheet
- AWS: Using presigned URLs
- FAST-VID: Why temporary media links expire
Try FAST-VID
Open the FAST-VID downloader for a supported public link. Keep session cookies and download links private; they are temporary credentials, not public URLs.