Bursary applications contain financial circumstances, home addresses, and vulnerable-pupil designations. myBursary treats that data accordingly - with defence-in-depth security across every layer of the stack.
Personally identifiable information (PII) is encrypted at the field level using strong, authenticated encryption before being written to the database.
Even if an attacker gained direct database access, they would retrieve only ciphertext. Encryption keys are stored separately from the application and injected at runtime - they are never written to disk or committed to source control.
Every connection - browser to application, application to database, and between internal services - is encrypted using modern protocols. Plain-HTTP requests are redirected to HTTPS automatically.
Access is controlled at every layer: authentication (who you are), authorisation (what you're allowed to do), and tenancy (which institution's data you can see). All views require authentication by default - public pages are an explicit, audited exception.
Students can self-register using their institution email address. Staff and admin accounts are created by an administrator only. All accounts are activated only after the user verifies their email address.
Every user is assigned one of three roles at account creation. Roles are enforced at multiple layers - a student cannot access staff views, and a staff member cannot access another institution's data.
Sessions are short-lived, reset on every request, and destroyed when the browser closes. Cookies carry full security attributes to prevent JavaScript access, cross-site forgery, and transmission over plain HTTP.
Sessions expire after a short period of inactivity. Every request resets the clock, so active users are never interrupted unexpectedly.
Sessions do not persist beyond the browser session. Closing the browser invalidates the session immediately.
Session and CSRF cookies carry the full set of browser security attributes to block JavaScript access, cross-site transmission, and plaintext exposure.
A strict set of HTTP response headers instructs browsers on where resources may be loaded from, whether the page can be framed, and how referrer information is shared. These headers defend against content injection, clickjacking, and other browser-level attacks.
Scripts, styles, fonts, and images may only be loaded from explicitly allow-listed origins. Unauthorised content injection and iframe embedding are both blocked.
Browsers are instructed to refuse plain-HTTP connections to myBursary for an extended period, even before the server responds.
Pages cannot be embedded as iframes on any origin, eliminating the clickjacking attack surface entirely.
Browsers are prevented from interpreting responses as a different content type than declared, closing a class of content-injection attacks.
Referrer information is restricted on cross-origin requests - external sites never receive the full URL of a page a user visited.
All state-changing requests carry server-validated anti-forgery tokens, preventing unauthorised actions from being triggered by third-party sites.
Each institution operates on its own subdomain. Tenant context is resolved and validated on every single request. Data belonging to one institution cannot be retrieved via another institution's subdomain - this is enforced at the data model level, not just by application logic.
Each institution gets its own subdomain. Requests on one subdomain cannot access resources or data belonging to any other institution.
Tenant ownership is embedded in every data record. Isolation is enforced at the data model layer - not just in application logic that could be bypassed.
Tenant context derived from incoming requests is strictly validated on every request before any data operation is performed.
The application runs in containers configured for minimal attack surface. Uploaded evidence files are stored privately and served via short-lived, signed URLs. All secrets are injected at runtime - nothing sensitive is baked into the image or committed to source control.
All containers run as unprivileged system users and are configured to prevent privilege escalation, even if a container is compromised.
The production image contains only what is needed to run the application. Build tools, source files, and development dependencies are not present at runtime.
Uploaded evidence documents are stored with private access controls and server-side encryption. Files are served via short-lived signed URLs - direct access is blocked entirely.
Services communicate over isolated internal networks. Backend services are not exposed to the internet.
Application secrets, database credentials, and encryption keys are loaded at startup from a secure environment. They are never written to disk or committed to source control.
Security configuration is validated automatically before deployment. The application will not start if a misconfiguration is detected.
All authentication forms are protected by invisible bot-challenge technology that distinguishes humans from automated scripts without presenting puzzles to legitimate users.
If you believe you have found a security issue in myBursary, please report it to us privately before disclosing publicly. We commit to acknowledging your report within 2 business days and working with you to resolve it.
[email protected]