Security implications & exposure vectors
Token-based authentication (passing tokens in URLs like https://app.com/board/SECRET_TOKEN) offers simplicity but introduces multiple security exposure points. This approach prioritizes usability over security—understanding the tradeoffs is critical.
Every component in the request chain sees and potentially logs the full URL, including your token:
Apache access.log, Nginx logs, IIS logs—all record complete URLs by default.
Cloudflare, nginx proxy layers, load balancers all see and log request URLs.
If serving through a CDN (Cloudflare, Fastly, AWS CloudFront), tokens are visible in their logs.
Tokens persist in browser history permanently—survives restarts, sync to cloud.
Google Analytics, Plausible, Matomo collect full URLs unless explicitly filtered.
Users accidentally share tokens when bookmarking or copy-pasting links.
When a user clicks an external link from your app, the browser sends the full URL (including token) in the Referer header:
GET /some-page HTTP/1.1
Host: external-site.com
Referer: https://yourapp.com/board/SECRET_TOKEN_HEREThe external site now has your user's token. This is the most dangerous exposure vector for URL-based tokens.
The Referrer-Policy header controls what information the browser includes in the Referer header. This is your primary defense against token leakage.
1. HTTP Header (Recommended - Global)
Set at the server level to apply across all pages:
server {
add_header Referrer-Policy "no-referrer" always;
}# .htaccess or VirtualHost
Header set Referrer-Policy "no-referrer"2. HTML Meta Tag
Add to <head> section of every page:
<meta name="referrer" content="no-referrer">3. Per-Link Attribute
Apply to specific external links:
<a href="https://external.com" referrerpolicy="no-referrer">
External Link
</a>https://app.com)no-referrer or same-origin to prevent token leakage to external sites. This is mandatory, not optional.
Minimum 32 bytes (64 hex characters) from cryptographically secure random source. Makes brute-force attacks infeasible.
Allow users to regenerate tokens with one click. Invalids old token immediately.
Tradeoff: User can lose access if they don't save the new token. Provide clear UI and confirmation.
Limit requests per token per IP/time window. Prevents brute-force and limits damage from leaked tokens.
Notify users of access from new IP addresses, countries, or unusual patterns. Consider blocking + requiring re-auth.
Enforce HTTPS everywhere. HTTP transmits tokens in plaintext over the network.
If security is a higher priority than simplicity:
Pass in Authorization header. Not logged by default, not in browser history.
JavaScript cannot access, more resistant to XSS. Automatic with requests.
Server-side session storage. Most secure but requires login flow + backend state.
Is URL-based token auth acceptable for your use case?