Security
We are a small team, so we keep the service simple, keep the attack surface small, and use well-understood defenses everywhere. This page describes what we actually do, what you can do to protect your account, and how to tell us about a vulnerability.
1. Accounts and sign-in
- Passwords are hashed with scrypt, a memory-hard algorithm, with a unique random salt per account. We never store or log your password, and we check new passwords against basic strength rules.
- Two-factor authentication with any standard authenticator app (TOTP) is available to every member, with single-use recovery codes. Authenticator secrets are encrypted at rest with a key kept outside the database, and recovery codes are stored only as hashes. Moderators and administrators are required to use two-factor authentication.
- Bot checks: the sign-in, sign-up and password-reset request forms are protected by Cloudflare Turnstile.
- Rate limits slow down password guessing, invite-code guessing, sign-up floods and other abuse, by IP address and by account.
- Sessions use random tokens that we store only as hashes, expire after 30 days without use, and can be reviewed and ended individually in Settings → Security. Changing your password signs out every other session.
- Sign-in alerts: we email you when your account is accessed from a new device (you can turn this off in Settings).
- Password reset links are single-use and expire after 30 minutes.
- Invite-tree containment: every account records the invite it came from, so a bot network that grows from one leaked code can be found and locked as a group in one action.
2. Data in transit
- All traffic is encrypted with TLS. Plain HTTP is redirected to HTTPS, and HTTP Strict Transport Security (HSTS) tells browsers never to connect without encryption.
- Traffic between Cloudflare's network and our server runs through an encrypted tunnel, so our server has no open inbound ports on the public internet.
- Cloudflare's firewall filters malicious traffic before it reaches us.
3. In your browser
- A strict Content Security Policy allows scripts only from our own domain (plus Cloudflare's Turnstile on the forms that use it) and forbids inline scripts, which shuts down most cross-site scripting attacks.
- There are no third-party scripts, fonts, trackers or analytics. Fonts are self-hosted.
- Session cookies are
HttpOnly,Secure,SameSite=Laxand use the__Host-prefix, so scripts cannot read them and other sites and subdomains cannot set them. - Every action that changes something is protected against cross-site request forgery.
- Pages cannot be framed by other sites, browsers are told not to guess content types, and private pages are never cached.
- Everything members write is escaped and rendered by our own code. No raw HTML or custom code from members is ever displayed, including on customized profiles, whose themes are plain data.
4. Content and media
- Uploads are checked by their actual content, not their file name, and size and length limits are enforced.
- Photos are re-encoded, which removes camera metadata such as GPS location. Videos are transcoded with their metadata removed. Animated GIFs are re-encoded frame by frame, which keeps the animation and drops embedded comment and XMP blocks.
- Media files are served only to signed-in members, under random, unguessable addresses, and never from a public bucket.
- Nothing on the service is visible to the public internet except the home, about and legal pages.
5. Infrastructure and staff access
- The service runs on hardware we operate in Las Vegas, Nevada. Server administration happens over private networks, not the open internet.
- Staff access follows least privilege: members, moderators and administrators have separate roles, and only administrators can change settings or roles.
- Every moderation action is written to an audit log.
- Data is backed up regularly, and backups rotate on a schedule similar to our retention schedule.
- We keep software up to date and patch security issues promptly.
- Private messages are protected by access control but are not end-to-end encrypted; the Privacy Policy explains what that means.
If a breach exposes your personal information, we will tell affected members by email without unreasonable delay, as described in the Privacy Policy.
6. What you can do
- Use a long, unique password, ideally from a password manager.
- Turn on two-factor authentication in Settings → Security and keep your recovery codes somewhere safe and offline.
- Review your active sessions now and then, and end any you do not recognize.
- Keep the email address on your account secure, because it can reset your password.
- Be suspicious of messages asking for your password, codes or invite codes. We will never ask for your password or your two-factor codes.
- Keep your own copies of anything important; export your data from Settings → Account.
7. Reporting a vulnerability
If you believe you have found a security vulnerability in The Social Web, please email [email protected] with "Security" in the subject line. Include:
- a description of the issue and its impact;
- the steps, requests or proof-of-concept needed to reproduce it;
- any affected URLs or accounts (use your own test accounts);
- how you would like to be credited, if at all.
We aim to acknowledge reports within five business days, keep you updated as we investigate, and tell you when the issue is fixed. Please give us a reasonable amount of time to fix the problem before you disclose it publicly, and coordinate the timing with us. We do not run a paid bug bounty program, but we are genuinely grateful and are happy to credit you publicly with your permission.
8. Safe harbor
We will not pursue or support legal action against you for security research conducted in good faith that follows this policy. Good faith means that you:
- only test against accounts you own, or accounts whose owners have given you explicit permission;
- do not access, modify, download or keep other members' data beyond the minimum needed to demonstrate the issue, and delete anything you did access once you have reported it;
- do not degrade the service for others (no denial-of-service, no spam, no high-volume automated scanning);
- do not use social engineering, phishing or physical attacks against our members, staff or facilities;
- report the vulnerability to us promptly and keep it confidential until we have had a reasonable chance to fix it.
If you follow these rules, we consider your research authorized, and we will not treat it as a violation of our Terms of Service. If a third party brings legal action against you for research that followed this policy, we will make it known that your actions were authorized. This safe harbor covers only systems we control; it cannot authorize testing against Cloudflare, Forward Email or other providers, which have their own policies.
9. Scope
In scope: https://thesocialweb.site and its API and WebSocket endpoints. Out of scope: denial-of-service; volumetric or automated scanning; social engineering; physical attacks; reports from automated tools without a demonstrated impact; missing best-practice headers or settings without a concrete exploit; clickjacking on pages with no sensitive actions; self-XSS; rate limits that slow but do not stop abuse; and issues in third-party services we use.
10. security.txt
Our machine-readable security contact is published at https://thesocialweb.site/.well-known/security.txt, following RFC 9116.