A Wake-Up Call for Philippine Schools
Recent reports of student information system (SIS) breaches have surfaced online, with sensitive student data — grades, personal details, enrollment records — being publicly exposed. While we will not name any specific institution or group involved, the technical details that have emerged paint a concerning picture of how many school systems remain vulnerable to attacks that are, frankly, preventable.
These incidents are not isolated. They reflect a systemic gap in how educational institutions approach data security — one that is now being publicly documented. SchoolBreach.org, a community resource tracking cybersecurity incidents affecting Philippine educational institutions, has cataloged over 30 incidents impacting millions of student records across multiple regions. For school administrators, IT staff, and edtech providers, this should serve as an urgent call to action.
What Went Wrong: The Key Vulnerability Patterns
The vulnerability shown in these incidents is a classic Broken Access Control issue — ranked as the number one risk in the OWASP Top 10. Unauthenticated API endpoints were returning sensitive records at predictable URLs. Here is a detailed breakdown of the patterns we identified:
1. Unauthenticated API Endpoints
Every route that returns school data must require a valid session or token. The most common mistake is adding authentication to the frontend (the login page) but forgetting the API layer behind it. This means the system looks secure to a normal user, but the underlying data is wide open.
For example, endpoints like these should never respond without a valid token:
GET /api/courses— should return 401 Unauthorized if no token is presentGET /api/courses/1234— same requirementGET /uploads/syllabus/prof_ramos.pdf— static files containing sensitive data need authentication too
Backend middleware must apply auth checks globally, not on a per-route basis. When authentication is applied selectively, it is only a matter of time before a developer forgets to protect a new endpoint.
2. Predictable and Sequential IDs (IDOR)
The exposed data showed records with IDs like 431, 432, 433 — simple sequential integers that make enumeration trivial. This is known as an Insecure Direct Object Reference (IDOR) vulnerability.
When IDs are sequential, an attacker does not need to hack anything. They simply increment the number in the URL and collect every record in the database, one by one. To mitigate this:
- Use UUIDs instead of auto-increment integers for any resource identifier exposed in URLs or API responses.
- Even authenticated users should only be able to access records that belong to their own school or tenant. An ID alone should never grant access — the system must verify ownership.
3. Multi-Tenant Data Isolation (Critical for SaaS Platforms)
For any SIS that serves multiple schools — especially cloud-based SaaS platforms — multi-tenant data isolation is the single biggest risk. Every database query must be scoped to the authenticated user's school or tenant.
Consider the difference:
- Dangerous: A query that retrieves a course by its ID alone, with no tenant filter. If a user from School A guesses the course ID of School B, they can see School B's data.
- Safe: A query that always includes the authenticated school's tenant ID. Even if a user guesses another school's course ID, the query returns nothing because the tenant filter blocks it.
This is not optional. It must be enforced at the data access layer so that no developer can accidentally bypass it.
4. Public File Storage and Directory Listing
Many school systems store uploaded files — profile photos, syllabi, report cards, scanned documents — in cloud storage buckets or server directories. If these storage locations are publicly accessible, anyone with the URL can download the files.
Key checks:
- Cloud storage buckets (Google Cloud Storage, AWS S3, etc.) must not be set to public access. Serve files through signed URLs with expiration times, or through an authenticated proxy endpoint.
- Directory listing must be disabled on your web server. No one should be able to browse
/uploads/or/static/and see a list of all stored files.
5. Lack of Rate Limiting and Monitoring
Without rate limiting, an attacker can send thousands of requests per second to extract an entire database. And without access logs and anomaly detection, breaches can go unnoticed for weeks or months.
Many of the breached systems had no mechanism to detect that large volumes of data were being extracted. Even basic monitoring — alerting when a single IP requests hundreds of student records in minutes — would have flagged the attack immediately.
6. Weak or Default Credentials
Some systems still ship with default administrator passwords, or allow simple passwords that can be easily guessed or brute-forced. Combined with the other vulnerabilities above, default credentials can turn a small exposure into total system compromise.
Why This Matters: The Real Impact on Students
When student data is exposed, the consequences go far beyond technical embarrassment:
- Identity theft: Student personal information can be used for fraudulent purposes, and minors are particularly vulnerable because they may not discover the theft for years.
- Discrimination and bullying: Leaked grades or disciplinary records can follow students and cause real harm.
- Legal liability: Under the Philippine Data Privacy Act (RA 10173), schools that fail to implement reasonable security measures face significant penalties, including fines and imprisonment for responsible officers.
- Loss of trust: Parents entrust schools with their children's most sensitive information. A breach fundamentally undermines that trust.
Security Checklist for School Owners
If your school uses a student information system — whether built in-house, purchased from a vendor, or provided as a cloud service — use this checklist to evaluate your system's security. Share it with your IT team or vendor, and ask them to confirm each item. We recommend reviewing this before onboarding and at least once a year.
1. Login and Access Control
| What to Ask Your Vendor or IT Team | Why It Matters | Priority |
|---|---|---|
| Does every part of the system require login — not just the main page, but also the behind-the-scenes data connections? | Some systems only protect the login page but leave the actual data exposed to anyone who knows the right web address. | Critical |
| When someone logs out, is their session immediately ended? | If sessions stay active after logout, someone using a shared computer could access another person's account. | High |
| Does the system limit what each user can see based on their role (admin, teacher, student, parent)? | A teacher should not see admin settings. A student should not see other students' grades. | High |
| Does the system lock accounts or flag unusual activity after multiple failed login attempts? | This prevents attackers from repeatedly guessing passwords until they get in. | High |
2. School Data Separation
| What to Ask Your Vendor or IT Team | Why It Matters | Priority |
|---|---|---|
| If the system serves multiple schools, is each school's data completely separated? | Without proper separation, a user at one school could potentially view another school's student records. | Critical |
| Can you confirm that there is no way for one school to access another school's data, even accidentally? | This is the most important question for any cloud-based system that serves multiple schools. | Critical |
| Is there a log of who accessed what data and when? | Audit logs help you investigate if something goes wrong and demonstrate compliance with the Data Privacy Act. | High |
3. Protection Against Data Scraping
| What to Ask Your Vendor or IT Team | Why It Matters | Priority |
|---|---|---|
| Are student records protected so that someone cannot simply guess web addresses to access them? | Some systems use simple numbered links (like record 1, 2, 3...) that make it easy to collect every record by changing the number. | Critical |
| Does the system verify that each user is authorized to view the specific record they are requesting? | Even logged-in users should only see data they are supposed to see — not every record in the system. | Critical |
| Is there a limit on how many records can be accessed in a short period? | Without limits, an attacker could download your entire database in minutes. | High |
4. File and Document Security
| What to Ask Your Vendor or IT Team | Why It Matters | Priority |
|---|---|---|
| Are uploaded files (report cards, IDs, photos, exam papers) stored privately — not on a publicly accessible link? | If files are stored on public links, anyone on the internet could find and download them. | Critical |
| Do file download links expire after a short time? | Temporary links ensure that even if a link is shared, it stops working after a few minutes. | Critical |
| Can someone browse a list of all uploaded files, or are files only accessible individually? | If someone can see a full directory of files, they can download everything at once. | High |
5. System Monitoring and Alerts
| What to Ask Your Vendor or IT Team | Why It Matters | Priority |
|---|---|---|
| Does the system detect and alert on unusual activity — such as someone downloading hundreds of records at once? | Many breaches go undetected for weeks because no one was watching for suspicious behavior. | High |
| Are error messages generic — meaning they do not reveal technical details about how the system works? | Detailed error messages can give attackers clues about how to break in. | High |
| Does the system limit how fast and how often data can be requested? | This prevents automated tools from extracting large volumes of data quickly. | High |
6. Infrastructure and Passwords
| What to Ask Your Vendor or IT Team | Why It Matters | Priority |
|---|---|---|
| Are all system passwords and secret keys stored securely — not written in plain text in the code or in documents? | If passwords are stored insecurely, anyone with access to the code can access the entire database. | Critical |
| Is the database inaccessible directly from the internet? | The database should only be reachable through the application itself, not by typing an address into a browser. | Critical |
| Does the vendor regularly check their software for known security issues? | Software libraries can have discovered weaknesses. Regular checks ensure these are patched promptly. | High |
| Are system accounts set up with the minimum permissions necessary? | If a system account has full administrative access when it only needs limited access, a breach becomes far more damaging. | High |
You do not need to be a technical expert to ask these questions. Share this checklist with your IT team or vendor, and ask them to confirm every item. A single gap at the Critical level can expose your entire school's data.
Beyond the Checklist: Building a Security Culture
A checklist is a starting point, not a finish line. Schools and SIS providers should also:
- Train IT staff in secure development practices (OWASP Top 10 at minimum).
- Train administrative staff in data handling best practices — security is not just an IT responsibility.
- Establish an incident response procedure and make sure everyone knows it.
- Review vendor security practices. Ask for documentation, evidence of penetration testing, and Data Privacy Act compliance. Include security requirements and breach notification clauses in contracts.
- Conduct regular penetration testing — not just automated scans, but manual testing by qualified professionals who think like attackers.
How OceanEd Approaches Security
At OceanEd, security is not an afterthought — it is foundational to how we build our platform. While no system is immune to all threats, we take a defense-in-depth approach:
- Every API endpoint requires authentication and authorization checks. Auth middleware is applied globally — there are no public-facing endpoints that return student data.
- Role-based access control (RBAC) ensures that users only see the data relevant to their role.
- Strict multi-tenant isolation ensures that every query is scoped to the authenticated school. One school can never access another school's data.
- Non-sequential identifiers are used for resource references, preventing enumeration attacks.
- File storage is private with authenticated access. No public bucket URLs or browsable directories.
- Rate limiting and request monitoring are built into our infrastructure.
- All data is encrypted in transit, and sensitive data is encrypted at rest — including personal information, grades, and confidential records such as guidance counselor notes.
- Regular security audits and penetration testing are part of our development cycle.
- We comply with the Data Privacy Act and maintain transparent data processing policies.
We share this not to market our product, but because we believe every SIS provider should meet these standards. Schools deserve technology partners who take security as seriously as they take features.
A Shared Responsibility
Securing student data is a shared responsibility between schools, technology providers, and regulatory bodies. Incidents like the ones recently reported should not be dismissed as the work of "hackers" — in many cases, the data was simply left exposed for anyone to find.
The Philippine education sector is rapidly digitizing. That is a good thing. But digitization without security is a liability. Schools must demand better from their technology providers, and providers must build systems that protect the communities they serve.
Digitization without security is a liability. Schools must demand better from their technology providers, and providers must build systems that protect the communities they serve.
What To Do If You Suspect a Breach
If you believe your school's SIS has been compromised:
- 1.Do not panic, but act quickly. Preserve evidence and avoid deleting logs.
- 2.Notify your Data Protection Officer (DPO). Every school should have a designated DPO under the Data Privacy Act.
- 3.Report to the National Privacy Commission within 72 hours if personal data of students has been compromised.
- 4.Engage qualified security professionals to investigate the scope of the breach.
- 5.Notify affected individuals (students and parents) as required by law.
- 6.Document and remediate. Fix the vulnerabilities that were exploited and document the entire incident response process.
References
- 1.Republic Act No. 10173 (Data Privacy Act of 2012). Establishes requirements for the protection of personal information in the Philippines, including security measures and breach notification obligations. RA 10173
- 2.OWASP Foundation. (2021). OWASP Top Ten Web Application Security Risks. Industry-standard guidance on the most critical web application security vulnerabilities, including broken access control and security misconfigurations. OWASP Top Ten
- 3.National Privacy Commission. (2023). NPC Advisory on Security of Personal Data in Educational Institutions. Guidance specific to schools on implementing appropriate organizational, physical, and technical security measures. NPC Advisories
- 4.SchoolBreach.org. A public resource tracking cybersecurity incidents affecting Philippine educational institutions, including breach timelines, severity assessments, and prevention recommendations. SchoolBreach.org
Written by
Ocean Team
Data Privacy & Compliance