Doing the homeworks to build rock-bottom solid trust for the community:
First, in this post, I'll present 6 points of critical vulnerabilities.
1) Open-source recon (nothing illegal)
The attacker maps the public site: rules, track pages, recent replays lists, upload form. Public pages confirm that replay packs/replays exist and hint at when/where publication happens.
Risk (general): if some replays are published live (or the site announces when they'll go public), rivals know where and when to watch.
2) Indirect enumeration
Without "forcing" anything, the attacker watches what the UI exposes:
"Download replay" links on past/current tracks.
Pages listing recent replays (including mobile/light views).
Risk (general): if "not-supposed-to-be-public" replays are listed because of a visibility bug (bad public/private flag), they become retrievable—no trickery needed.
3) Logic flaws around "quiet days / visibility"
Competitions often have a "hide my time" mode. If the implementation has a logic bug (e.g., a direct link that isn't re-checked server-side, or a visibility parameter that's only client-side), a "hidden" replay may still be downloadable via an old link, a guessable URL, or a mirrored/cached page. (This is a design risk, not a claim about any specific site.)
Risk: a discreet leak of RPLs during the race—enough to copy lines and pacing.
4) Webroot storage & predictable names
If .rpl files live under a web-accessible folder and have guessable names (increments, timestamps), then:
Someone may stumble onto them via referrers, proxy caches, or a copy-pasted partial URL.
A bot could index a pack that's already public with rich metadata (driver, track, car) and make it discoverable.
Risk: "accidental" exfiltration (referrers, indexing, mirrors), even without malicious intent.
5) Leaks via headers or caches
Without proper headers (Cache-Control, Content-Disposition, Referrer-Policy), a private replay that passes through a CDN/proxy or a third-party site can leave downloadable traces (temporary copies, request logs, referrers exposing paths).
Risk: persistent copies outside your control.
6) Admin/backup leakage
Backups (DB/zips) left under webroot, unprotected admin pages, protected and compromised admin features, or an auto-generated "replay pack" export that isn't locked down can expose all RPLs for a month in a single request.
Risk: mass compromise in one shot.
The next post will discuss how to -hopefully- fix that.
Securing Competition Replay Systems: Risk Assessment & Mitigation Guide
Based on analysis of common attack vectors against racing simulation replay systems, here's a comprehensive security review with practical fixes for each identified risk.
1. Open-Source Reconnaissance
Risk: Attackers map public site structure (rules, track pages, replay lists, upload forms) to understand when/where replays are published. If replays go live during active competitions, rivals gain tactical advantages.
Fix:
Implement publication delays - don't release replays until competition phases end
Use randomized publication schedules instead of predictable timing
Consider staged disclosure: public replays only after all participants have submitted
Rate limit access to replay listing pages to prevent automated mapping
Obfuscate timing information in public APIs/pages during active competitions
2. Indirect Enumeration via UI Exposure
Risk: UI accidentally exposes "private" replays through download links, recent replay lists, or mobile views due to visibility flag bugs.
Fix:
Server-side validation for ALL replay requests - never trust client-side visibility flags
Separate databases/tables for public vs private replays
Whitelist approach: explicitly mark what's public rather than hiding what's private
Regular audits of all replay listing endpoints (including mobile/API versions)
Access logging to detect unusual download patterns
3. Logic Flaws in "Quiet Days" / Hidden Mode
Risk: "Hide my time" features with implementation bugs allow access to hidden replays via direct links, guessable URLs, or client-side bypass.
Fix:
UUID-based replay IDs instead of sequential/predictable naming
Token-based access control: require valid session tokens for any replay access
Server-side re-validation on every request - check visibility status fresh from database
Expire old URLs - implement time-limited access tokens
Separate storage paths for public/private replays with different access controls
4. Webroot Storage & Predictable Names
Risk: Replay files stored in web-accessible directories with guessable names (increments, timestamps) become discoverable through referrers, caches, or bots.
Fix:
Move replays outside webroot entirely - serve through application layer only
Cryptographically random filenames (UUIDs) instead of sequential naming
Authentication required for ALL replay downloads
Content-Disposition headers to prevent direct linking
X-Accel-Redirect/X-Sendfile for efficient protected file serving
5. Header & Cache Leakage
Risk: Missing security headers allow CDNs, proxies, and third-party sites to cache private replays or expose paths via referrers.
Fix:
Cache-Control: private, no-cache, no-store, must-revalidate
Content-Disposition: attachment; filename="replay.rpl"
Referrer-Policy: no-referrer
X-Robots-Tag: noindex, nofollow, noarchive, nosnippet
HTTPS-only for all replay traffic
CDN bypass for private content or proper CDN auth configuration
Monitor referrer logs for unexpected replay URL exposure
6. Admin/Backup Exposure
Risk: Database backups, admin pages, or bulk export features left web-accessible can expose entire replay collections in single requests.
Fix:
Remove ALL backups from web-accessible directories
IP whitelist admin interfaces + multi-factor authentication
Separate admin domains not linked from public site
Audit file permissions regularly - ensure proper .htaccess/web.config rules
Encrypted backup storage with separate access credentials
Export functionality should require admin authentication + audit logging
Additional Recommendations
Content Security Policy headers to prevent replay embedding on external sites
Regular penetration testing focused on file access controls
Monitoring/alerting for unusual download volumes or access patterns
Legal frameworks - clear terms of service regarding replay usage rights
The key principle: assume any web-accessible content will be found. Design your system so that even if someone discovers a replay URL, proper authentication and authorization still protect sensitive content.
Those problems are easy to solve if we address them patiently.
Before I start addressing the specific points, I have to ask: how much AI assistance did you get compiling the text above? Some of the behaviours and problems listed are assumption (or hallucinations) that have no connection with how ZakStunts works. So it's useful for me to understand if you wrote from the point of view of "these are specific things I can pinpoint on the website" (proof of concept would be useful), "this is how I assume the system works" (let's discuss how things actually work), or got support from a bot who gave you a list of possible problems.
Beyond that, I have to point out that you are using the terms "critical vulnerabilities" and "whistleblower" incorrectly. There might be a lost-in-translation situation here, so please be patient — English is not the first language for either of us.
I don't write a single line for my posts—it's all automated. You're absolutely right to point out that I'm functionally illiterate when it comes to web design, security, and maintenance. My only skill is vibe coding.
Thanks for the advice—I've moved Hyperion Racing Team behind Cloudflare, and I hope our future exchanges will teach me a thing or two more.
Quote from: Alain il professore on August 16, 2025, 11:27:28 PMYou're absolutely right to point out that I'm functionally illiterate when it comes to web design, security, and maintenance. My only skill is vibe coding.
And yet, France Stunts lives again!
Thanks for explaining, that saves me going through all the points above as if they were relevant to the current ZakStunts. But let's see if I can ease some of your worries:
- ZakStunts does not use replay files, it stores everything in the database
- Because access goes through the database, there is only one way to download a replay, and that code checks that the replay is public, or the race is over
- The website does not use numeric identifiers, so no-one can enumerate results or replays
- Download links use the replay hash (e.g., https://zak.stunts.hu/replays/97c987d7271641e830a2bcaab5ad3f6c77f300c0); no-one can guess the link, unless they already have the replay
- There are no downloadable backup files stored on the server
Great explanation, I love the bullet points because it's easier to read and that will help mitigate -some- fears.