Skip to content

Security: MrLemonOff/AlgoWorld

SECURITY.md

Security policy

Supported versions

Security fixes go into the latest release. Please update before reporting a problem.

Version Supported
1.x (latest) Yes
Older No

Reporting a vulnerability

Please do not open a public issue for a security problem.

Use GitHub's private reporting instead: open the Security tab of this repository and click Report a vulnerability. Describe what you found, how to reproduce it, and what an attacker could do with it. You will get an answer as soon as possible, and credit in the release notes if you want it.

How AlgoWorld is meant to run

AlgoWorld is built for a trusted local network: a home, a club or a classroom, where one computer hosts and friends join over Wi-Fi. It is not designed to be exposed directly to the internet. If you put it behind a reverse proxy or a tunnel anyway, you do so at your own risk, and you should add your own authentication in front of it.

What protects your friends and your computer

The host panel

  • The host panel and its API only answer requests that come from the host computer itself (loopback address) and carry the secret host key.
  • The key is random (192 bits), created at every start, printed only in the AlgoWorld window, and kept in an HttpOnly, SameSite=Strict cookie.
  • Requests carrying proxy headers (X-Forwarded-For, Forwarded, X-Real-IP, CF-Connecting-IP) are refused, so a tunnel on the host computer cannot turn visitors into the host.
  • The host has no access to anyone's code, messages, boards, streams or screen. There is no admin account and no master password.

Accounts and sessions

  • Passwords are hashed with bcrypt (cost 11) and never stored or logged in clear. A password must have at least 8 characters and must not contain the username.
  • Sessions are random 256-bit tokens in HttpOnly cookies; only their SHA-256 is stored. Signing in starts a new session, changing a password ends the other sessions.
  • Sign-ins are rate-limited per address, and an account is locked for a few minutes after repeated wrong passwords. Unknown usernames and wrong passwords take the same time and get the same answer.
  • Bans and chat mutes have a reason and an end, and disconnect the person at once.

Requests

  • Every state-changing request needs a custom header and a same-origin Origin (CSRF protection).
  • Every input is validated (zod schemas, size limits per route, per-user and per-address rate limits, flood limits on every realtime event).
  • A strict Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, frame protections and other headers are set by helmet.
  • Slow or oversized requests are cut (header and request timeouts, a limit of open connections per address).

Running code and showing files

  • Algorithm and C programs run in a Web Worker with a time limit and a memory budget.
  • Python runs in Pyodide inside a Web Worker, with the JavaScript bridge, network access and dangerous modules removed, and a fresh worker for every run.
  • Uploaded pictures are checked by their content, not their name. Office files are converted with every macro disabled.
  • Streamed web pages are loaded by the server through an SSRF-safe proxy (private and local addresses are refused, DNS is pinned) and shown in a sandboxed frame; viewers see a replay of the page, never its scripts.
  • Zip files (backups, slides) are read with limits on the real unpacked size, so a "zip bomb" cannot fill the memory.

Data

  • Everything is stored on the host computer in the data folder, written atomically with a .bak copy. Backups contain password hashes: keep them private.
  • The logs record sign-ins, host actions and security events. They never contain passwords or message contents.

Tests

npm test runs, among others, a realtime and security test that starts a private server and checks the host key, proxy and remote refusals, CSRF, access to other people's scripts, bans, mutes, closed pages and settings validation.

There aren't any published security advisories