Please do not open a public issue, discussion or pull request for a security problem. Report it privately using one of the channels below. A public report shows everyone how to exploit the problem before it is fixed.

Supported versions  ·  Reporting  ·  What happens next  ·  Scope  ·  Testing rules  ·  How it's protected

Dofus Forge is a continuously deployed web app, not a library you install. Security fixes go to the live site; old versions are never patched.

The current version is in VERSION and in the app's What's new dialog.

A good report includes:

• What is affected: the URL, Worker route, Supabase table or RPC, workflow, or file and line number.
• Impact: what an attacker can read, change or break, and whose data or account is affected.
• Steps to reproduce, using only your own test accounts and data.
• Proof: request and response pairs, screenshots or a short recording. Redact any token, cookie or personal data.
• Suggested fix, if you have one. This is welcome but not required.

Please don't send real user data, other people's credentials, or anything you got by accessing an account that isn't yours.

Dofus Forge is maintained by one person in their own time. The timings below are goals the maintainer works toward, not a contractual service level.

If the report is accepted:

1. The fix is developed privately and tested.
2. It ships through the normal dev → main deploy. A database change ships as a migration under supabase/migrations/.
3. A GitHub security advisory is published once the fix is live. You are credited by name or handle if you want to be.
4. The What's new changelog mentions the fix without exploit details.

If the report is declined (out of scope, intended behavior, or no realistic impact), you get a short explanation. If you disagree, reply with more detail and the report will be reviewed again.

Please give us a reasonable chance to fix the issue before you disclose it publicly. Coordinated disclosure normally happens when the fix is live, or after 90 days if no fix has shipped, whichever comes first. Agree the date with the maintainer.

There is no paid bug bounty. Good reports get public thanks and a credit in the advisory.

• Third-party services: the DofusDude API, Google AdSense and Fonts, Cloudflare Turnstile, Discord, GitHub, and the Supabase and Cloudflare platforms themselves. Report problems in those to the vendor.
• Denial of service, load or stress testing, and any spam or volume attack against production.
• Things that are public by design:
  • the Supabase URL and anon (publishable) key in the browser bundle;
  • public builds, profiles and comments;
  • anyone who knows an unlisted build's link can read that build. The link itself is the access key.
• Findings that only report something missing, with no demonstrated impact: a header, an SPF/DMARC record, a cookie flag, a rate limit, or a CSP still in report-only mode.
• Self-XSS, clickjacking on pages with no state-changing action, CSV injection, or reports that only work in an outdated or modified browser.
• Social engineering, phishing, or physical attacks against the maintainer, contributors or users.
• Problems in forks or self-hosted copies that are not in this repository's code.

Not sure whether something is in scope? Report it anyway, privately.

If you research in good faith and follow these rules, we will not pursue or support legal action against you, and we will treat your report as authorized:

• Use your own accounts. Create two test accounts and use one as the attacker and the other as the victim. Never touch real users' data, sessions or accounts.
• Prove the issue with as little as possible. Stop once you have shown the problem exists. Don't pivot further, dump data or keep access.
• Don't degrade the service. No DoS, no flooding, and no automated scanner pointed at production at volume. Keep any scripted checks to a handful of requests.
• Don't change or delete other people's content, and clean up the test content you created.
• Prefer local testing. Everything in this repo runs locally: pnpm dev, pnpm test, and supabase start loaded with supabase/schema.sql. You can reproduce most database issues against a local stack instead of production.
• Keep the details private until the fix is live.

Active testing beyond these limits, such as load tests or anything against infrastructure we don't own, needs written permission first. See docs/security/TESTING_AUTHORIZATION.md. This safe harbor covers Dofus Forge only. It does not authorize testing of third-party services, and it does not override their terms.

A short description of the security model, so researchers can spend their time where it matters. The full picture is in docs/security/.

Browser (React SPA) ──anon key / user JWT──► Supabase: Postgres RLS · column grants · SECURITY DEFINER RPCs
        │
        └──► dofusforge.com (Cloudflare) ──► static assets (public/_headers)
                                         └─► Worker: /og · /build · /img/item · /char

The most recent full audit was on 2026-10-27: a source-level review with independent verification of every lead. The fixes shipped in 0.3.135; see the CHANGELOG.

• Never commit secrets. .env is ignored by Git. Anything prefixed with VITE_ ends up in the public browser bundle.
• Database changes ship as an idempotent migration in supabase/migrations/, are appended to supabase/schema.sql, and get a guard in src/test/schema.test.ts. Read docs/security/ACCESS_CONTROL.md before touching RLS.
• Worker changes keep src/worker/securityHeaders.ts and public/_headers in sync. A test fails if they drift apart.

More in CONTRIBUTING.md.

_{Thank you for helping keep every adventurer's builds safe.
Maintained by Juan (Wembie).}