MySelf·Lab demo · noindex

🎯 Red team test — rules of engagement

MySelf-Lab is a showcase deliberately exposed to attack. It inverts OWASP Juice Shop: here the application is protected by the MySelf ecosystem (SelfRecover, SelfDataGuard, SelfModerate), and the goal is to prove — or disprove — that protection under real conditions. Anyone following the rules below is authorised to carry out research here.

📊 The lab in numbers

33days online
11authentication attempts repelled
0reports received
0flag captured

Aggregated from data the lab already collects — no audience measurement, no tracking cookie, no address retained.

📍 Scope

✅ In scope

  • The MySelf-Lab web application (this site) and all its paths
  • SelfRecover authentication (sign-up, log-in, recovery)
  • SelfDataGuard encrypted private messages and profiles
  • SelfModerate reputation and voting
  • The report submission form below

⛔ Out of scope

  • Any infrastructure, domain or service other than this site
  • The server's SSH service (port 22) — authentication attempts there trigger a network-level block that would also cut off your access to this site
  • The hosting provider, the registrar, third-party suppliers
  • Accounts or data belonging to real people
  • The maintainer's machine, accounts and mailboxes

An extended scope (other MySelf components) may be agreed privately with a selected team, under written agreement. It is not published here.

🏁 Objectives (capture the flag)

A demonstration account holds, in its personal memo, a secret in the form:

FLAG-… (encrypted end-to-end, client-side — AES-256-GCM, key derived from the user's secret, never present on the server)

The target account name will be given to you when the test opens. Neither a database dump, nor administrator access, nor full control of the server reveals this secret — the key exists only in its owner's browser. The challenge is to bring it back in the clear.

MITRE ATT&CK and OWASP references are given per objective (web application vulnerabilities map to OWASP/CWE, outside the ATT&CK scope).

✅ Allowed

  • Web application testing: injection (SQL, command), XSS, IDOR, authentication bypass, business logic
  • Cryptanalysis of SelfDataGuard blobs
  • Attempts to dump the database through an application flaw
  • Reasoned fuzzing of endpoints
  • Interception and replay within scope

⛔ Forbidden

  • Denial of service, flooding, volumetric stress (DoS / DDoS)
  • Social engineering aimed at real people, the maintainer or the hosting provider
  • Physical attacks, or attacks on premises
  • Pivoting or scanning outside the declared scope
  • Destruction, encryption (ransomware) or permanent alteration of data
  • Mass exfiltration beyond proof; spam; illegal content

⏱️ Technical note — rate limiting

The authentication endpoints (/api/login.php, /api/register.php) are rate-limited to 10 requests per second, with a burst allowance of 20.

A 429 response signals this rate limiting — or the account's anti-brute-force lockout. It is not a denial of service you caused, and there is no need to report it as one.

Reasoned fuzzing is unaffected: only massively parallel requests are. No ban is applied — on this server, scanning is part of the game.

🧭 Responsible conduct

🛟 Safe harbour

As long as your research follows these rules, we consider it authorised and carried out in good faith. We will take no action against you, and we will do our best to clear up any uncertainty quickly. If in doubt about the scope or a technique: ask before you act, using the form below.

📨 Submit a report

🔒 The body of your report is encrypted at rest by SelfDataGuard before storage: the database holding it reveals nothing but a blob. The module you are testing protects your report too.

🌐 These rules exist in French and English. In case of discrepancy between versions, the French text prevails.

🏆 Hall of fame

No validated contribution yet. Be the first to appear here.