@revxxx Please shut down the site. It’s a safety hazard to your users.
9 Likes
Some of which are in this forum I recommend that people delete their accounts on that site and change their passwords for things they use online. Also potentially making your bank aware of a potential leak of your info.
1 Like
Yup this is why I said what I said earlier. I’m glad you went through the effort to demonstrate this so I didn’t have to.
It’s pretty obvious that if you don’t even bother to change the style Claude Code defaults to for every website it makes, you don’t care enough to do even the most basic security essentials.
At least don’t let people have access to your directory that’s really bad. Sheesh.
Re: Security Concerns
I want to thank you for taking the time to report these issues rather than exploiting them silently. I take this seriously, and I owe the community full transparency on what happened, what you were able to access, and what I’ve done about it.
What you found and how it worked:
The admin panel pages were being protected by client-side JavaScript only, meaning the HTML was served to anyone who visited the URL, even though the underlying API that handles data required server-side admin verification. What you saw in those screenshots was the admin UI shell loading in your browser. The JavaScript auth check could be bypassed by disabling JS or simply viewing the page source. This is a legitimate and embarrassing oversight on my part.
Directory listing was also enabled, which let you browse the file structure. That’s how you found the admin pages and other files - Apache was happily showing you everything in each folder.
Regarding premium access – the premium gates are enforced server-side on every API endpoint (the server checks the database, not what the browser claims). What you most likely did was manipulate the client-side JavaScript to make the UI appear as though you had premium. It looks convincing in a screenshot, but the server would still reject any actual premium API calls. That said, the fact that you could even see the admin dashboard and its structure was a real problem that should never have been possible.
What I’ve done (already deployed):
- Every admin page now has server-side PHP authentication - non-admins receive a 403 before a single byte of HTML is sent
- Directory listing is disabled - no more “Index of” pages anywhere
- Security headers added - HSTS, X-Frame-Options, X-Content-Type-Options, and others are now enforced
- CORS locked down - all 50+ API endpoints now only accept requests from my own domain, not from anywhere on the internet
- Rate limiting added to login, registration, and password reset endpoints
- Sensitive directories blocked - cron jobs, logs, data files, and config files are no longer web-accessible
- All API keys and credentials are being rotated
- Additional fixes for information leakage, open redirect, and other issues identified during the audit
In total, I identified and patched around 25 vulnerabilities across 65+ files. I’ve also had a comprehensive security audit done covering SQL injection, XSS, CSRF, authentication, authorisation, file upload, SSRF, and server configuration.
Addressing the broader criticism:
You’re right that I moved too fast and didn’t have adequate security review before going live. That’s on me. But I disagree that the answer is to shut down. The answer is to fix it - which is what I’ve done. Every platform has had security issues at some point; what matters is how you respond.
No user payment data was compromised - No payment details are ever stored on my server. Session tokens use cryptographic randomness and bcrypt password hashing. The database uses prepared statements throughout (no SQL injection). These fundamentals were always in place, but the access control layer on top had real gaps that I should have caught.
I’m not going to pretend this wasn’t a wake-up call. It was. But I’d rather fix the problems and build something better than walk away from the community that uses this platform.
If you or anyone else finds further issues, I’d welcome responsible disclosure - my contact is support@funscript.org
1 Like
The fact that any of this was ever an issue is unacceptable. I think it goes without saying that Eroscripts will no longer work with funscript.org. That said I’m curious about a couple things.
- Who performed the security audit. I’m betting it was all AI because no responsible security analyst would perform a less than 24 hour pentest.
Session tokens shouldn’t have any encryption at all. A proper token (JWT) is base64 encoded.
They’re encrypted already with TLS.
Your authentication token is stored in localStorage. This is very insecure and should be moved to a cookie. The only cookies I see are google analytics tokens.
Prepared statements do not eliminate SQL injection. They only abstract the input into a confined box where SQL injection is harder to perform.
The auth token being in localStorage is enough for me to know no real security audit was performed. I am advising you shutdown. If you don’t I will permanently ban you and make a public post advising people to delete their accounts citing security issues. It is more harmful to the community to continue to operate.
4 Likes
I understand and respect the decision to discontinue working with Funscript.org. No hard feelings - you have a community to protect and I appreciate that you’ve always been straightforward.
I want to address a couple of technical points for clarity, not to argue, but because accuracy matters when security is the topic:
On session tokens: The tokens use bin2hex(random_bytes(32)) for generation - that’s cryptographically secure randomness, not encryption. They’re opaque tokens validated against a server-side database session, which is a deliberately chosen pattern. It allows immediate server-side revocation (deleting the row invalidates the session instantly), which JWTs can’t do without additional infrastructure like a revocation list. This is the same approach used by GitHub and Stripe for their API tokens. Both approaches are valid - this one was chosen for its simplicity in session invalidation.
On prepared statements: Parameterized queries are the primary defense against SQL injection as recommended by OWASP. When values are bound as parameters, they are sent to the database separately from the SQL statement and are never parsed as SQL. They don’t just make injection “harder”, they prevent the bound values from being interpreted as SQL at all. That’s the whole point of parameterisation.
On localStorage: You’re right that this was a weakness, and it was flagged in the audit. As of this morning, authentication also uses HttpOnly, Secure, SameSite=Lax cookies for server-side page authentication. The localStorage token is still used for JavaScript API calls, but the sensitive server-side access control no longer depends on it.
On the audit: Yes, the initial rapid response used AI tooling to identify and patch vulnerabilities at speed, because when someone is publicly demonstrating access to your admin panel, you don’t wait for a two-week engagement. That said, I am bringing in an independent security professional to conduct a proper penetration test as a follow-up. The emergency response and the formal audit serve different purposes, and I’m doing both.
All issues raised in the original post have been verified as resolved. Every admin page now enforces server-side PHP authentication. Directory listing is disabled. Sensitive files and directories return 403. Security headers are enforced. CORS is restricted to the site’s own domain. Rate limiting is in place on all auth endpoints.
I wish EroScripts and the community well, and I’m grateful for the years of support.
3 Likes
This thread will serve as a post-mortem.
20 Likes
I did not expect this to get legal. He ran an insecure site made with ai stole scripts and paid for advertising and when these issues were found out and made public he charged back for advertising and is now blackmailing this forum into lying about his site being secure in order to gain back users. I think more people need to see this you can not remain a user on that site in good conscience.
5 Likes