Security

Purpose

This page documents the security requirements and operational controls for the Maqsafy platform.

Security controls should cover authentication, authorization, data protection, audit logging, tenant isolation, network security, secure configuration, and monitoring.

Security References

The Maqsafy dashboard SRS requires TLS 1.2+, encryption at rest, secured credential identifiers, RBAC, tenant isolation, audit logs, rate limiting, and brute-force protection.

Recommended security references:

• OWASP ASVS for application security verification requirements.
• OWASP Top 10 for common web application security risks.
• NIST SP 800-53 Rev. 5 for security and privacy control catalog.

Authentication Security

Control	Requirement
Secure login	All dashboard users must authenticate securely
Password reset	Password reset must follow a controlled workflow
MFA	MFA should be available for Admin and sensitive financial actions
Failed login protection	Repeated failed attempts should be rate-limited
Session protection	Session tokens must not be exposed in logs or URLs

Authorization and RBAC

The system must enforce role-based access control across all dashboard actions and API endpoints.

Role	Security Scope
Admin	Platform-wide control with audit requirements
School Manager	Assigned school scope only
Supplier	Supplier-specific scope only
Operator	Assigned cafeteria/operator scope only

Tenant Isolation

Tenant isolation is mandatory.

Rules:

• Schools must not access other schools' data.
• Suppliers must not access other suppliers' records.
• Operators must only access assigned cafeteria/operator records.
• Backend queries must enforce scope-based filtering.
• Reports and exports must respect user permissions.

Data Protection

Data Type	Protection Rule
Passwords	Must be hashed, never stored in plain text
Access tokens	Must not be logged or exposed
OTP values	Must not be logged or documented
Student data	Must be minimized and access-controlled
Financial records	Must be auditable and protected
Credential identifiers	Should be secured, tokenized, or hashed where feasible

Network Security

Control	Requirement
TLS	Production traffic must use TLS 1.2 or higher
HTTPS	Public endpoints must use HTTPS
Internal services	Database and Redis must not be publicly exposed
Reverse proxy	Nginx or equivalent proxy should enforce secure routing
Firewall	Only required ports should be exposed

API Security

API endpoints must enforce:

• Authentication
• Authorization
• Input validation
• Rate limiting
• Tenant isolation
• Secure error handling
• Audit logging for sensitive actions

Sensitive Actions

The following actions should be audited:

• Login failures
• User role changes
• Financial approvals
• Refund actions
• Withdrawal approvals
• Credential assignment
• Credential deactivation
• Credential replacement
• Exporting sensitive reports
• Integration configuration changes

Audit Logging

Audit logs should include:

Field	Description
Actor	User or system performing the action
Action	What was changed or executed
Timestamp	When the action occurred
Scope	School, supplier, operator, or platform scope
Before / After	Previous and new values, where applicable
Reference ID	Traceable identifier for support and investigation

Logging Rules

• Do not log passwords.
• Do not log access tokens.
• Do not log OTP values.
• Do not log private keys.
• Do not log full card, bracelet, or credential secrets.
• Do not log unnecessary student personal data.
• Logs must support troubleshooting without exposing sensitive data.

Secure Configuration

Production configuration rules:

• APP_DEBUG=false
• Secrets must be stored outside source code.
• Production .env files must not be committed to Git.
• Default passwords must not be used.
• Unused services and ports must be disabled.
• Error messages must not expose stack traces to end users.

Dependency Security

Rules:

• Review package vulnerabilities.
• Update dependencies based on risk and compatibility.
• Avoid unsupported packages.
• Test updates before production deployment.
• Do not apply breaking dependency upgrades directly to production.

File Upload Security

For uploads such as support attachments, invoices, or images:

• Restrict allowed file types.
• Enforce file size limits.
• Store files securely.
• Do not execute uploaded files.
• Scan files where applicable.
• Restrict access based on role and scope.

Backup Security

• Backups must be access-controlled.
• Backup files should be encrypted where applicable.
• Restore access must be limited to authorized personnel.
• Backup download links must not be public.
• Backup retention rules must be documented.

Incident Response Notes

For security incidents:

1. Identify the affected system.
2. Preserve relevant logs.
3. Restrict access if needed.
4. Rotate affected credentials.
5. Patch the root cause.
6. Verify the fix.
7. Document the incident and corrective actions.

Security Rules

• Do not include real secrets in documentation.
• Do not include production credentials.
• Do not include real tokens.
• Do not include private keys.
• Do not include customer personal data.
• Use placeholders for all sensitive examples.