Skip to content

Security: AkashVarma007/Chaos-Controller

Security

SECURITY.md

Security Policy

Supported versions

Chaos Controller is a pre-1.0 project developed on main. Only the current main branch receives fixes; there are no maintained release branches.

Version Supported
main ✅
tagged releases ❌ (none published yet)

Reporting a vulnerability

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

  1. Preferred: open a private advisory via GitHub Security Advisories.
  2. Alternative: email g.akashvarma@gmail.com with [SECURITY] in the subject.

Include the affected file or endpoint, reproduction steps, and what an attacker gains. This is a solo-maintained project — expect an initial reply within about a week, not within hours.

Security model

Read this before deploying anything here. Several properties that look like security controls are not.

The simulator does not attack anything

Everything under src/components/red/ and src/store/simulationLogic.ts mutates local React/Zustand state in the browser tab. "Traffic flood", "region outage", and "network partition" change numbers in a store; they emit no network requests, spawn no processes, and touch no infrastructure. There is no load-generation capability in this repository, and none should be added without an explicit authorization gate.

Client-side RBAC is not an authorization boundary

useSimulationStore.hasPermission() and the viewer / operator / admin roles gate UI affordances only. The role lives in browser memory and can be changed from devtools in one line. Do not treat it as access control, and do not port this pattern to a context where the guarded action has real consequences. The same applies to the audit log: it is an in-tab record, not tamper-evident.

The backend has no authentication

Every endpoint in server/ is declared expose: true with no Encore auth handler:

  • POST /ecom/orders
  • GET /ecom/health
  • GET /metrics/blue/snapshot
  • GET /metrics/blue/history

/metrics/blue/* will hand aggregate traffic data to any caller that can reach it. This is intended for localhost development only. Before exposing the server on any network, add an auth handler and restrict the metrics endpoints.

Input handling: POST /ecom/orders validates userId and each item's productId and quantity before doing anything, and rejects with ErrCode.InvalidArgument. Nothing is persisted, interpolated into a query, or passed to a shell — there is no injection surface today, but the validation must stay in front of any storage layer added later.

Frontend environment variables are public

VITE_METRICS_API_BASE is read via import.meta.env and is inlined into the production bundle at build time. Anything prefixed VITE_ is shipped to every visitor in plaintext. Never put an API key, token, or credential in one. The repository ships .env.example with a localhost default and git-ignores real .env files.

Local persistence

Feature flags, rate-limit configuration, and per-session audit logs are written to localStorage unencrypted (src/core/storage/adapters/local.ts). It is simulation data, but it is readable by any script running on the same origin.

Out of scope

  • The Encore development dashboard (localhost:9400) and its exposure model.
  • Vulnerabilities in third-party dependencies — report those upstream, though a heads-up here is welcome if this project pins an affected version.
  • Attacks that require the reporter to already have write access to the machine running the dev server.

There aren't any published security advisories