How we protect your account
Security & privacy
Built for a technical audience, so here is the real detail: exactly how accounts, passwords, and requests are handled, and the precautions baked into the code. No hand-waving, and nothing claimed that isn't actually in place.
Accounts & passwords
- Sign-in runs on the site's own service at Cloudflare. Passwords are hashed with PBKDF2-SHA-256 (100,000 rounds, a random salt per account) and stored only as that hash - your plaintext password is never logged or stored.
- New passwords must be at least 8 characters and pass a strength check (a mix of at least three of: lowercase, uppercase, digit, symbol; common and repeated passwords are rejected). A live meter enforces it in the create-account dialog, and the same rule is re-checked on the server before the account is created - so it holds even if someone bypasses the browser.
- Google and GitHub sign-in were retired in October 2026. An account that used either one keeps everything it had: choose “Forgot your password?” with the same email address to set a password.
- Sessions use a signed token that expires after one hour. The token that renews it is single-use, stored only as a hash, and changing your password signs out every other session.
- Sign-in attempts and reset emails are rate limited, and a reset link works once and expires after an hour.
- An account is optional for most of the site - browse, plan, share links, and read every page without one. Voting and commenting require an account, so a rating or a reply counts a person rather than a browser.
Transport & delivery
- HTTPS everywhere: plain-HTTP and www requests are 301-redirected to the canonical secure origin.
- HSTS (
Strict-Transport-Security, one year) tells browsers to refuse an insecure connection to the site in the first place.
Request integrity
- Every state-changing API call (saving a build, voting, editing a profile, moderation) is checked for a same-origin request before it runs, so another site can't drive actions with your session.
- Serverless endpoints validate and bound their inputs - IDs, revisions, and payload shapes are verified, and account ownership is enforced from the verified identity, not from anything the client claims.
Browser-hardening headers
- Content Security Policy restricts scripts, styles, images, and connections
to this origin plus a short, named allow-list;
frame-src 'none'andobject-src 'none'block embedded frames and plugins. - X-Frame-Options: DENY - the site can't be framed, defeating clickjacking.
- X-Content-Type-Options: nosniff stops MIME-type guessing.
- Referrer-Policy: strict-origin-when-cross-origin keeps full URLs from leaking to other sites.
Voting, comments, and identity
- Voting requires an account. It previously accepted a browser cookie this site issued itself, which made a fresh identity one cache-clear away. A vote is now tied to a signed-in account and stored as an HMAC-SHA256 derivation of the account id, so the vote table never holds the id itself. An account is not proof of a distinct person either, but it costs a verified email rather than a deleted cookie.
- Posting a comment and reporting one require an account too, keyed the same way. Reading a thread never does. Reporting matters most here: the database allows one report per person per comment so that a single actor cannot bury a comment under manufactured reports, and a cookie anyone can reset defeats that guarantee.
- As a result the site no longer issues a guest identity cookie at all. If your browser still holds one from before, it is read once - when you sign in - so that a vote you cast earlier moves onto your account, and only the derived key is ever stored.
Data we keep - and don't
- For an account we store your email and a display name you choose. That's it.
- Saved builds and your tier list are private by default; profiles are private until you explicitly opt in to a public one.
- Third-party code, named in full: Google Analytics measures which pages get read, Ezoic supplies the consent manager, and Google AdSense serves the ads. Each sets its own cookies and is subject to the choices you make in the consent banner. Our own code keeps only anonymous totals - page views, the kinds of page opened and searches made, with no cookie and no identifier - and nothing on this site profiles you for us. The Content-Security-Policy names exactly which domains may load scripts, images, frames and beacons; everything else is refused.
Architecture
The site is a statically generated set of pages served as flat files, with a small serverless API for the community features. There's no traditional application server to compromise and the attack surface is deliberately minimal - most of the site is just HTML that can't do anything dangerous.
Reporting a vulnerability
Found something? We want to hear it. Email help@lolclassicwiki.com with the details and we'll get back to you. Please don't publicly disclose an issue until we've had a chance to fix it.
See also the legal & privacy page for data-retention, deletion, and the full disclaimer.