Skapp Cyber Hack

The rulebook

Rules

How Skapp Cyber Hack works: what to submit, how findings are scored, and how to test responsibly. Break the rules of engagement and you’re out.

01 / At a glance

At a glance

Kickoff · submissions open
Wednesday, November 4 at 4:30 PM GMT+5:30, on Google Meet
Submissions close
Wednesday, November 18 at 4:30 PM GMT+5:30
Duration
14 days
Crew registration closes
Wednesday, November 4 at 4:30 PM GMT+5:30. Rosters lock then.
Crew size
Exactly 3 Rootcoders
Proof per finding
Up to 10 files, 25 MB each
Upload storage
300 MB per crew

Skapp Cyber Hack is played in crews of 3. Crews register themselves on the home page, file findings together and share one score. There’s no minimum number of findings: every accepted one earns points.

02 / The crew

Form your crew

  1. 01Register. Anyone on the crew opens Register your crew on the home page and enters the crew name, a logo, and the name and @rootcode.io email of all 3 members. No sign-in needed.
  2. 02Sign in. When submissions open, each member signs in with Google using the email the crew registered.
  3. 03Compete. Any member can file findings for the crew, and crewmates see each other’s reports.
  • The first member listed is the crew captain.
  • To change the name, logo or a member after registering, contact the organisers.
  • Each Rootcoder can be on only one crew. The same email can’t be registered twice.
  • Pick a crew name no other crew has taken, and keep it suitable for a work event.

03 / Writing a report

Writing a report

File one vulnerability per report. A triager should be able to reproduce it from your report alone. Every report has these parts:

  1. 01Title. One line naming the issue and where it is.
  2. 02Component / endpoint. The affected URL, service or resource.
  3. 03Steps to reproduce. Numbered and exact, so a triager can follow them.
  4. 04Proof. A screenshot, request/response or short clip. Show one clear record, not a dump.
  5. 05Impact. What an attacker gains, in one or two sentences.
  6. 06Suggested fix. Optional. Earns bonus points and speeds up remediation.
  • Chained issues that only matter together can go in one report. Explain the chain in the steps.
  • Duplicates: the first valid report of an issue scores. Later ones are rejected as duplicates.
  • Don’t split one issue into several reports, e.g. the same XSS on many pages.

04 / Severity

Severity

You don’t rate your own findings. Reviewers set the severity of each accepted finding by its realistic impact, not the bug class, so make the impact clear in your report.

criticalRemote code execution, authentication bypass, SQL injection dumping user data, admin takeover.10 pts
highTaking over another user’s account, reaching admin-only functions, leaking tokens or personal data.6 pts
mediumStored XSS, CSRF on important actions, IDOR on non-sensitive records, SSRF without internal reach.3 pts
lowVerbose errors, missing security headers, self-XSS, weak rate limiting with no clear impact.1 pt

05 / Scoring

Scoring

  • Only accepted findings score, at the severity reviewers assign.
  • A useful suggested fix can earn a +1 bonus on an accepted finding, at the reviewer’s discretion.
  • Ties go to the crew that reached the score first, measured by when its latest accepted finding was filed.
  • Pending and rejected findings score nothing.

Standings update live on the leaderboard.

06 / Review

Review

  1. 01In review. Every new finding waits for an organiser. While it’s in review, whoever filed it can delete it, which frees its storage.
  2. 02Accepted or rejected. The reviewer confirms it, rates its severity, and can leave you a note.
  3. 03Final. Once reviewed, a finding is locked. Ask an organiser if you think a decision is wrong.

07 / Rules of engagement

Rules of engagement

Do

  • Test only the targets announced by the organisers. Everything else is out of scope.
  • Use your own test accounts. Create extra ones if you need to prove cross-account issues.
  • Stop at a minimal proof of concept. One record or one request is enough.
  • If you reach real personal or sensitive data, stop, don’t keep it, and report it straight away.

Don’t

  • No denial of service, load testing or heavy automated scanning.
  • No social engineering, phishing or physical attacks.
  • Don’t change or delete data you didn’t create, or pivot to other systems.
  • Don’t share findings outside the event, or attack other Rootcoders or this site.

08 / Files & privacy

Files & privacy

  • Accepted proof formats: PNG, JPG, GIF, WebP, MP4, WebM, MOV, TXT, LOG, JSON, HAR and PDF. Screenshots can be pasted straight into the form.
  • Each crew shares 300 MB of storage. Deleting a finding that’s still in review frees its space.
  • Your reports and files are private. Only your crew and the organisers can see them.
  • Redact passwords, tokens and other people’s personal data from screenshots and captures.