Loading…NepEdu keeps many schools' records in one place. A single leak across that boundary would end this company, and would do real harm to real children. So we design for that first and add features second.
Every record belongs to exactly one school, and every query is filtered by the school the request came from. The filter fails closed: if we cannot positively establish which school you belong to, you get nothing back, rather than everything. That default is the difference between a bug and a breach.
Hiding a button is not security. Every permission is checked on the server, on every request, both when reading data and when writing it. A user who crafts a request by hand gets exactly the same answer as one who clicks around the screen.
Teachers see the students in the classes they actually take, not the whole school. Guardians see their own children. Students see themselves. Administrative detail, like who last edited a record, is kept from guardians and students entirely.
Changing or resetting a password signs out every device, immediately. A stolen session cannot quietly outlive the password reset that was meant to kill it, which is exactly the gap most systems leave open.
Repeated failed sign-ins get locked out, and abusive traffic is throttled. We have built the lockout so that it cannot be dodged by an attacker, and cannot be turned around and used to lock a colleague out of their own account on purpose.
Records carry an audit trail of who created and last changed them, and deletions are reversible rather than destructive. When a school asks what happened to a record, there is an answer.
Security is mostly discipline, repeated. No single item below is clever. Doing all of them, every week, is the whole job.
Every connection to NepEdu is served over HTTPS with certificates renewed automatically. There is no unencrypted path into the platform.
School data is backed up automatically, and we practise restoring it. A backup nobody has ever restored from is a hope, not a backup. We do not publish the schedule; schools who need it can ask.
The application runs no analytics, advertising or third-party tracking scripts. Student data is not a product we sell, and it is not used to train AI models.
We audit our own code adversarially, and every security issue we find is fixed and then pinned by a regression test that runs on every change, so the same hole cannot quietly reopen a year later.
New fields are exposed deliberately, never by wiring a model straight through to the API. It is the kind of shortcut that leaks password hashes, so we do not take it.
Changes to authentication, tenancy or permissions get the closest review we give anything, because those are the three places where a small mistake becomes everyone's problem.
This page is deliberately short on internals. We will not publish the shape of our defences to the whole internet, but we will tell a school that is trusting us with its children’s records. Just ask.
Email us with enough detail to reproduce it, and give us a reasonable chance to fix it before you publish. We will confirm we received your report, keep you posted, and credit you if you would like us to.
Please do not test against a real school’s data, and do not access, change or download records that are not yours. Report it instead: we will take it seriously, and we will not come after a researcher who acted in good faith.