Security Assessment of the World Monitor application
National Technical Research Organisation (NTRO) · Miscellaneous · Software
Unusually clear and tractable because you get the source and a live target, but it is a skills demonstration not a build — worth it for a team with real security experience who can find and document non-trivial vulnerabilities, since that depth is the only differentiator.
Data: App: worldmonitor.app | Source: github.com/koala73/worldmonitor
What it actually is
This is a penetration-testing exercise on a specific real application whose source code and live instance are both provided. The task is to find security vulnerabilities across authentication, access control, input handling, API and client-side security, demonstrate them safely as proof-of-concept, rate their severity and recommend fixes — the classic security-audit deliverable, scoped to one named target.
What to build
A structured security assessment of the World Monitor application: review the provided source code and test the live instance across the named scope — authentication and session management, authorization and access control, input validation, API security, client-side controls, secure communication and data storage — and for each vulnerability found produce a documented finding with a title, affected component, CVSS severity, reproduction steps, a safe proof-of-concept, a business-impact assessment and a remediation recommendation, all within the stated constraints of testing only the authorized target and limiting exploitation to proof-of-concept.
Smallest thing that wins the room
Walk through one well-documented vulnerability end to end — for example a broken access-control flaw letting one role reach another's data — showing the reproduction steps, a safe proof-of-concept, the CVSS rating and the concrete remediation, backed by the code location that causes it.
How crowded this one gets
A guess, projected from the 2025 statements — the last year where both the submission counts and the winners were published.
Quieter than 36% of the 226 · #144 of 226 by expected field
A normal-sized field. Your idea has to be good, not miraculous.
Why: defence, intelligence and space bodies drew small fields.
This is a guess, not a fact
Nobody has published 2026’s numbers yet. This is an analysed estimate from last year’s pattern, so please do not take it as the truth — check the live counter on the SIH portal before you decide anything. The range covers the middle half of likely outcomes, so one statement in two lands outside it. Entry closes at 500 ideas per statement, so no range goes past that — a statement that reaches the cap fills and shuts rather than drawing an unlimited crowd. The model reads only three things a team can see before choosing — software or hardware, the theme, and what kind of body posted it — and those explain about a quarter of the variation in last year’s field sizes (R² 0.25 on held-out statements). Trust the band more than the number, and the ordering more than either. It cannot see how good your idea is, which is the part that actually decides it.
The scores
The number is the shorthand. The line under it is the reason.
Acceptance potential
3/5It is highly achievable and the white-box setup with real code is a genuine advantage, but it is a skills-demonstration task rather than a build, so it is won on the depth and quality of the findings rather than on any novelty — a team that finds several real, well-documented vulnerabilities does well, but there is no product to differentiate on.
Feasibility
4/5Both the live app and the full source code are provided, which makes this a white-box assessment — the most tractable kind — and the required skills are standard web-security testing with well-known tooling, so a team with security exposure can execute it directly.
Innovation scope
2/5This is a defined penetration-testing task with a standard deliverable format, so there is little to design or invent — the work is finding and documenting real vulnerabilities, not creating a novel system.
Clarity
5/5The target, the scope, the constraints, the success criteria and the exact per-vulnerability deliverable format are all specified precisely, making this one of the most unambiguous statements in the entire set.
Effort
MediumAuditing one application with source available is bounded work, though thorough coverage across the full scope and clean write-ups take real care.
Demo-ability
EasyA live proof-of-concept exploit against the actual application, with the causing code shown, is concrete and immediately convincing to a security judge.
In its favour
- Green flag: Both the live application and full source code are provided, making this a white-box test which is far more tractable than black-box
- Green flag: The deliverable format is specified exactly, so there is zero ambiguity about what to produce for each finding
- Green flag: A live proof-of-concept against the real app with the causing code shown is concrete, convincing evidence
- Green flag: The clear success criterion — at least one valid documented vulnerability — means a competent team can be confident of a baseline result
Against it
- Red flag: This is a skills task with no product to build, so it is won purely on the depth and quality of findings, and a shallow assessment finding only trivial issues will not stand out
- Red flag: Every team attacks the identical target, so your findings will be directly compared and duplicate discoveries dilute impact
- Red flag: The constraints require testing only the authorized target with proof-of-concept-only exploitation, and violating them is disqualifying
- Red flag: Strong findings require genuine web-security skill, so a team without security experience will surface only superficial issues
What you will be writing
- Burp Suite / OWASP ZAP web testing
- Source code security review (Semgrep / manual)
- OWASP Top 10 methodology
- CVSS scoring
- API security testing (Postman / custom)
- Proof-of-concept exploit development in a sandbox
- Penetration testing
- Web application security
- Vulnerability assessment
Prior art to read before you start
white-box security assessment · web application penetration testing · vulnerability documentation and remediation
Analysed by Claude Opus. Every score above is a judgment call with its reasoning attached — kindly cross-check this against the official statement on the SIH portal before your team commits to it.