Security

1. Executive Summary

Alpha Supreme Services LLC operates a workforce management platform that processes sensitive employee and business data including personal identifiers, wage information, performance evaluations, and disciplinary records. This Security White Paper outlines the technical and organizational measures we implement to protect the confidentiality, integrity, and availability of all data entrusted to our Platform.

2. Security Architecture Overview

Our Platform is built on a modern, defense-in-depth architecture designed to minimize attack surface and enforce least-privilege access at every layer:

• Frontend: React single-page application served over HTTPS with Content Security Policy headers
• Backend: Managed cloud infrastructure with PostgreSQL database, serverless edge functions, and secure file storage
• Authentication: Industry-standard authentication with multi-factor verification
• Authorization: Row-Level Security (RLS) policies enforced at the database layer

3. Authentication and Identity

3.1 Multi-Factor Authentication (MFA). All login attempts require a two-step verification process. After valid credential submission, a time-limited 6-digit one-time password (OTP) is delivered via email. OTPs expire after 10 minutes and are single-use.

3.2 Password Security. Passwords are hashed using industry-standard bcrypt algorithms. Plaintext passwords are never stored or logged. Password reset is a staff-moderated workflow: clients cannot perform self-service resets, preventing account takeover via email compromise.

3.3 Session Management. Sessions are automatically terminated after 30 minutes of user inactivity. A 2-minute warning is displayed before expiration. Session tokens are stored securely and refreshed automatically during active use.

3.4 Account Provisioning. Public user registration is disabled. All accounts are created exclusively by authorized staff through a secure, MFA-protected provisioning workflow. This eliminates unauthorized account creation vectors entirely.

4. Authorization and Access Control

4.1 Role-Based Access Control (RBAC). The Platform enforces two primary roles:

• Staff: Administrative users with cross-company visibility and management capabilities
• Client: Business representatives restricted to data for their assigned companies only

4.2 Row-Level Security (RLS). All database tables enforce RLS policies that filter data access at the database engine level, not at the application layer. This ensures that even if application-level checks are bypassed, the database will refuse unauthorized data access.

4.3 Role Assignment Security. Roles are assigned via a database trigger that always defaults new users to the "client" role, ignoring any client-side metadata. Role escalation to "staff" requires execution of a privileged database function by an existing staff member. RLS policies on the `user_roles` table prevent any user from modifying their own role.

4.4 Master Account. A single master administrative account exists with elevated privileges including user deletion and cross-role password resets. This account is protected by the same MFA and session controls as all other accounts.

4.5 Company-Level Isolation. Client users can only access data associated with their assigned companies. Company assignments are managed exclusively by staff. A security-definer function validates company access at the database level for every query.

5. Data Encryption

5.1 In Transit. All data transmitted between the client browser and our servers is encrypted using TLS 1.2+ (HTTPS). No unencrypted HTTP connections are accepted.

5.2 At Rest. Database storage is encrypted at rest using AES-256 encryption provided by our cloud infrastructure provider. File storage buckets for documents, onboarding files, and paystubs are similarly encrypted.

5.3 Secrets and API Keys. Sensitive credentials (third-party API keys and integration tokens) are stored in an encrypted vault using PostgreSQL's vault extension. Access to vault contents is restricted to staff-role users and service-role functions via security-definer database functions.

6. Rate Limiting and Abuse Prevention

The Platform implements server-side rate limiting to prevent brute-force and abuse attacks:

• Login code requests: Maximum 5 attempts per email per 15-minute window
• OTP verification: Maximum 10 attempts per email per 15-minute window
• Sliding window cleanup: Expired rate limit records are automatically purged via database triggers to maintain performance

Rate limiting is enforced at the database level via a dedicated table and security-definer function, ensuring it cannot be bypassed by application-layer manipulation.

7. Input Validation and Sanitization

All edge functions enforce strict server-side input validation:

• UUID format validation for all entity identifiers (regex-enforced)
• Email format and length validation (max 255 characters)
• OTP format enforcement (exactly 6 digits)
• Role whitelisting to prevent privilege escalation via crafted payloads
• Request body parsing occurs before any authentication calls to prevent timing attacks

8. File Storage Security

8.1 Private Buckets. All file storage buckets (documents, onboarding files, and paystubs) are configured as private. No public access is permitted.

8.2 Signed URLs. File access is granted through temporary signed URLs with a 1-hour expiration. This prevents unauthorized long-term access to stored files even if a URL is leaked.

8.3 Path-Based Security. All file uploads use a user-ID-prefixed path structure. RLS policies on storage buckets validate that the requesting user owns the file or holds a staff role.

9. Audit Trail and Monitoring

9.1 Activity Logging. All significant platform actions are recorded in a centralized activity log via database triggers. Logged events include:

• Record creation, modification, and deletion across all modules
• Status changes (submissions, approvals, rejections, completions, and voids)
• Document uploads and deletions
• Administrative actions (user creation, password resets, and role changes)

9.2 Immutability. Activity log entries are insert-only. No update or delete operations are permitted, preserving the integrity of the audit trail.

9.3 Attribution. Every log entry is attributed to the authenticated user who performed the action, with timestamps recorded in UTC.

10. Secure Communications

10.1 Transactional Email. All platform-generated emails (verification codes, review notifications, and disciplinary warnings) are sent through a dedicated email service provider with SPF, DKIM, and DMARC authentication configured.

10.2 Tokenized Links. Employee-facing links (performance review responses and disciplinary acknowledgments) use cryptographically random tokens with configurable expiration periods. Tokens are single-use and invalidated upon response submission.

10.3 SMS Security. SMS messages are limited to transactional purposes (verification codes and account alerts). SMS consent data is not shared with third parties. See our Privacy Policy for full SMS terms.

11. Infrastructure Security

• Managed Infrastructure: Our cloud provider handles OS patching, network security, and physical security for all servers
• Edge Functions: Serverless functions run in isolated Deno runtimes with no shared state between invocations
• Database Isolation: Each project receives a dedicated PostgreSQL instance with network-level isolation
• Automated Backups: Database backups are performed automatically by the infrastructure provider

12. Vulnerability Management

• Dependencies are regularly audited and updated to address known vulnerabilities
• The application uses security-definer functions to prevent SQL injection through parameterized queries
• All user-supplied data is treated as untrusted and validated before processing
• Security findings are triaged and addressed based on severity

13. Incident Response

In the event of a security incident:

• Detection: Monitoring of authentication failures, rate limit triggers, and anomalous access patterns
• Containment: Ability to immediately suspend user accounts and revoke sessions
• Notification: Affected parties will be notified within 72 hours of confirmed breach, per our Data Processing Agreement
• Remediation: Root cause analysis, security patch deployment, and process improvements

14. Compliance and Legal

• CCPA: California Consumer Privacy Act compliance for California residents
• TCR/10DLC: SMS messaging compliance with The Campaign Registry standards
• Data Retention: Configurable retention policies with secure deletion procedures
• Jurisdiction: All data is stored and processed within the United States, governed by California state law

15. Contact and Reporting

To report a security vulnerability or concern, contact us at admin@ass.services. We take all reports seriously and will respond within 48 hours.