RosarioSIS is a student information system. Its data model includes students, parents, staff, courses, grades, attendance, billing, and school communication. The application may present a portal login or a school website, but the protected surface is the set of records and actions available to each user profile.
ZoomEye count-only measurements on 2026-11-09 between 23:46 and 23:47 UTC returned 556 assets for app="RosarioSIS", four for title="RosarioSIS", and 15,696 for the product name in the HTTP body. The query used sub_type=all, page 1, and page size 1. The body count is much broader than the application fingerprint and should not be treated as an installation count.
The application-fingerprint result is the strongest product signal here. The title result is sparse, which suggests that many deployments do not expose the product name in the HTML title. The body query can include documentation, portals, and links. All three numbers describe different collection behaviors.
Profiles are the permission surface
RosarioSIS documentation and built-in help describe profiles such as Administrator, Teacher, Parent, and Student. The User Profiles page controls which programs a profile can use and whether the profile can read or edit records in those programs. The help text recommends testing with a user in the relevant profile rather than assuming that a menu item accurately represents the permissions.
That advice is the right starting point for a review. A teacher profile might need access to a course roster but not to billing records. A parent should see their own student, not another household. An administrator may need broad configuration access while a front-office account needs data entry without system settings.
The permission model can also be layered with plugins and REST API access. A plugin should not become a way around the page-level profile check. API credentials need their own scope and lifecycle. A token issued for a mobile application should not inherit an unrestricted administrator profile by default.
Measurement method
The SDK requested one record per dork with sub_type="all", page 1, and page size 1. It recorded exact totals and did not retrieve full asset records. The public search link uses the application fingerprint, which is the most specific positive signal. An authorized reviewer should confirm the login and administration paths before adding a host to inventory.
These counts do not show whether a school has exposed student records. They show that RosarioSIS appears in the index and that the body signature is much more common than the title signature. The version, authentication method, and profile configuration remain local facts.
A review plan for school IT
Start with a complete profile inventory. List every active profile, the programs it can use, and whether it can edit, delete, or export data. Check for custom profiles that were created for a one-time project and never removed.
Test horizontal boundaries. A parent account should not be able to change a student identifier and read another family. A teacher should not see another teacher's restricted records. Use synthetic test students where possible and keep evidence free of real student information.
Review API and integration tokens. Identify which systems import grades, attendance, or billing data. Confirm the token's owner, scope, lifetime, and revocation process. If an integration only needs to read a roster, it should not be able to change grades or financial records.
Check the hosting and reverse-proxy layout. A school may run RosarioSIS on a shared web host, a district server, or a managed platform. Restrict administrative paths, enforce HTTPS, and confirm that backup files and database dumps are not reachable from the web root.
What the count cannot prove
The 556 application matches do not establish that every instance is internet-accessible, unpatched, or misconfigured. The 15,696 body matches are not a count of student-information systems. The four title matches suggest that title-based discovery would miss most of this sample.
The useful conclusion is that product fingerprinting can find a population that title search misses, but it cannot answer the permission question. The next step is inside the school: verify profiles, test cross-account access, and connect every integration token to a documented business need.