Security Policy

SMS was designed with security as a foundational principle, not an afterthought. Every architectural and operational decision — from data storage to access management — is made with the protection of school and student data as the primary concern.

We do not publicly disclose the specific technologies, vendors, or implementation details of our infrastructure. This is a deliberate security practice — reducing the surface area of information available to potential adversaries. This document describes our security commitments in outcome-based terms.

Per-School Data Isolation

Every school registered on SMS receives a dedicated, isolated data store. This is our most fundamental security design decision:

• School A's data is physically and logically separated from School B's data at the storage layer.
• A security event affecting one school's data store cannot cascade to another school's records by architectural design.
• There is no shared data layer where a misconfigured query or permission error could accidentally expose another school's information.
• Access credentials for each school's data are unique and rotated as part of provisioning.

Cloud & Edge Infrastructure

The SMS backend runs on enterprise-grade, globally distributed cloud infrastructure. This architecture provides:

• No persistent server processes susceptible to long-running exploitation — requests are handled in isolated, short-lived execution environments.
• Automatic Distributed Denial of Service (DDoS) mitigation at the network edge, before traffic reaches our application.
• Web Application Firewall (WAF) protection at the perimeter.
• Regional failover and high availability managed at the infrastructure level.

We intentionally do not name our specific infrastructure providers in public documentation to reduce the information available for social engineering and targeted attacks.

Encryption at Rest

• All data stores — including school databases — are encrypted at the storage layer using industry-standard encryption algorithms.
• Application secrets, credentials, and cryptographic keys are managed using secure secret management practices. They are never stored in source code, version control systems, or application configuration files accessible at runtime.
• Signing secrets used for authentication tokens are unique per deployment environment and rotated on a defined schedule.

Encryption in Transit

• All connections between users and SMS use HTTPS, enforcing industry-current TLS protocol versions. Older, insecure protocol versions are rejected.
• HTTP Strict Transport Security (HSTS) is enabled on all domains and endpoints.
• All internal service-to-service connections are also encrypted in transit.
• Cross-Origin Resource Sharing (CORS) is configured to permit requests only from authorised, verified origins.

Password & Credential Security

Token-Based Authentication

Permission-Based Access Control

SMS implements fine-grained, permission-based access control enforced at both the server (API) and client (UI) levels:

• Every page, feature, and API endpoint is protected by specific permission requirements. Users without the required permission are denied access.
• The School Owner holds full administrative access. All other users are restricted to the permissions explicitly assigned to their role.
• Permissions are re-validated from live data at each session refresh — not cached indefinitely from the initial login.
• Role and permission changes take effect within one access token lifetime — typically within minutes.
• The School Owner can immediately revoke any user's access by deactivating their account.

Parent & Guardian Access

• Parent and guardian accounts are strictly scoped to data linked to their own children only — enforced server-side on every API request.
• Attempts to access another student's data via API manipulation are rejected with an access-denied response, regardless of the request's form.

• CORS: Strictly configured to permit requests only from verified, authorised frontend origins. Wildcard or open-origin configurations are not used in production environments.
• Rate Limiting: Authentication endpoints, password reset flows, and other sensitive operations are rate-limited to prevent brute-force attacks, credential stuffing, and automated abuse.
• DDoS Protection: Network-layer and application-layer DDoS mitigation is active at the infrastructure level, protecting against volumetric and application-targeted attacks.
• Bot Management: Automated bot detection and management is applied across authentication and sensitive API endpoints.
• Security Response Headers: All HTTP responses include appropriate security headers, including content-type protection, clickjacking prevention, and a restrictive Content Security Policy (CSP).
• HSTS: HTTP Strict Transport Security is enforced, requiring all browsers to interact with the platform exclusively over HTTPS.

Input Validation

• All data submitted to the platform via API is validated against strict, defined schemas before processing. Inputs that do not conform are rejected with structured error responses.
• String inputs are sanitised, trimmed, normalised, and length-checked. This prevents common injection patterns and data pollution.
• Email addresses, school codes, and other structured fields are validated against well-defined formats before acceptance.

Injection Prevention

• All database interactions use parameterised, type-safe query construction. Raw SQL strings are never assembled from user-supplied input, preventing SQL injection attacks at the design level.
• Strong type enforcement means that type mismatches between expected and received data are caught before execution.

Frontend Security

• Our web application framework provides built-in Cross-Site Scripting (XSS) protection by automatically sanitising all data rendered in the user interface.
• Navigation guards enforce authentication and permission checks on every page transition within the application.
• Session token storage is implemented in a manner that protects against common Cross-Site Request Forgery (CSRF) attack vectors.
• Authentication sessions are managed automatically, including graceful handling of token expiry and renewal.

Dependency & Supply Chain Security

• Third-party software dependencies are regularly audited using automated security scanning tools.
• Critical security vulnerabilities in dependencies are patched within 48 hours of public disclosure.
• Production builds use pinned dependency versions to prevent supply-chain drift and unexpected changes between deployments.

Our incident response process is structured around these phases:

We welcome reports from security researchers, ethical hackers, and users who discover vulnerabilities in our platform. If you believe you have found a security issue:

• Report it to us privately at security@sms.app with a clear description of the vulnerability, steps to reproduce it, and your assessment of its potential impact.
• Please do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and remediate — we ask for a standard 90-day window.
• Do not exploit the vulnerability beyond what is minimally necessary to demonstrate its existence.
• Do not access, modify, delete, or exfiltrate data belonging to any school or user.
• Do not conduct automated vulnerability scanning without prior written authorisation from our security team.

Security is a shared responsibility. Our platform provides strong technical controls, but the security of your school's environment depends on practices at your end too. We expect schools to:

• Use Strong Passwords: Enforce strong, unique passwords for all staff accounts. Avoid reusing passwords across multiple services.
• Apply Least Privilege: Assign users only the minimum permissions they need to perform their role. Review and revoke unnecessary access regularly.
• Maintain Account Hygiene: Deactivate accounts of staff members who leave the school or change roles promptly.
• Secure Devices: Ensure all devices used to access SMS are protected with passwords, screen locks, and up-to-date operating system security patches.
• Recognise Phishing: Train staff to identify phishing attempts. We will never ask for your password via email, phone, or chat. Any such request is fraudulent.
• Report Suspicious Activity: Immediately report any suspected unauthorised access, unusual behaviour, or security concern to security@sms.app.
• Obtain Required Consents: As the Data Fiduciary for your school community, ensure appropriate parental or guardian consent has been obtained before entering any student's personal data into the platform.

For security vulnerability reports, suspected incidents, or security-related questions:

For encrypted communication regarding sensitive security matters, please contact us first at security@sms.app to arrange a secure channel.