Security & Responsible Disclosure
We build a platform used by school students, so security is not optional. If you have found a vulnerability, this page tells you exactly how to tell us and what we commit to in return.
Researchers Are Welcome Here
Every system has defects, and the ones nobody reports are the dangerous ones. We would far rather learn about a weakness from a researcher acting in good faith than from a student who was harmed by it. If you have found something, we want to hear from you — and we will treat your report as a contribution, not an accusation.
This platform serves children, which raises the stakes and shapes our priorities. Issues that could expose participant information, allow certificate results to be forged, or compromise a visitor’s device are treated as our most serious class of problem and are triaged ahead of other work.
We do not currently operate a paid bug-bounty programme, and we would rather say so plainly than imply a reward we cannot honour. What we can offer is a prompt, respectful response, a genuine fix, and public credit for your finding if you would like it.
What This Policy Covers
Please keep your testing within these boundaries.
In Scope
The website at www.inspiretalenthub.in and its pages, including the Study Hub, the Results Portal and the certificate verification tool.
Out of Scope
Third-party services we merely use (such as our form relay, font provider and DNS or hosting providers). Please report those to their own security teams.
Not a Vulnerability
Missing best-practice headers with no demonstrated impact, automated scanner output without a working proof of concept, social engineering of our staff, and self-inflicted browser-console actions.
Never Acceptable
Denial-of-service testing, spam, physical attacks, accessing or modifying data belonging to real participants, or any action that degrades the service for students.
How to Report an Issue
One address, and as much detail as you can reasonably give.
Email info@inspiretalenthub.in with “Security” in the subject line. A useful report describes what the issue is, the exact steps or requests needed to reproduce it, what an attacker could realistically achieve with it, and the browser or environment you used. A short proof of concept — a URL, a screenshot, a minimal snippet — is worth more than a long description.
Please report the issue privately first and give us reasonable time to fix it before publishing details. We consider ninety days a fair default, and we are happy to agree a different timeline with you if the issue warrants it. Coordinated disclosure protects the students using this platform while your finding is being resolved.
The same contact details are published in machine-readable form at /.well-known/security.txt, following the RFC 9116 standard, so automated tooling and researchers can find the correct channel without hunting through the site.
Our Commitment to You
If you follow this policy, you have nothing to fear from us.
- We will not pursue legal action against researchers who act in good faith and within this policy.
- We will acknowledge your report, normally within five working days.
- We will give you an assessment and an expected timeline once we have triaged the issue.
- We will keep you informed as the fix progresses, and tell you when it has shipped.
- We will credit you publicly for the finding if you want to be named, or keep you anonymous if you prefer.
- We will never share your identity with third parties without your consent.
Testing Responsibly
Use only your own accounts and your own test data. If you encounter information belonging to a real participant, stop immediately, do not save or share it, and tell us what you found so we can assess the exposure. Access only the minimum necessary to demonstrate the issue — proving a door is unlocked does not require walking through the whole building.
Do not degrade the service for anyone else. Avoid automated scanning that generates heavy traffic, do not attempt denial of service, and do not modify or delete data that is not yours. Remember that on the other side of this platform are students in the middle of a competition or a revision session.
How We Reduce Risk by Design
Some of our security comes from what we deliberately do not build.
The public website is static: pre-rendered pages served from a CDN, with no application server or database behind them. There is no public login on the main site, no server-side query layer, and no session state to hijack. A large share of the vulnerability classes that affect conventional web applications simply do not apply here, because the machinery they target does not exist.
We also minimise what we hold. The Study Hub keeps a student’s progress in their own browser’s local storage rather than on our servers, we set no cookies of our own, we run no analytics or advertising code, and we load no third-party JavaScript. Data we never collect cannot be breached. Our technology page sets out this architecture in detail, including the two external services we do rely on.
Explore more: