Security Policy

1. Security Overview

ERPRev Dashboard ProMax employs a defense-in-depth strategy with multiple layers of security controls:

• Zero Trust — Every request is authenticated and authorized. No implicit trust is granted based on network location.
• Least Privilege — Users and system components are granted only the minimum permissions necessary.
• Encryption Everywhere — Data is encrypted both in transit and at rest, with special handling for sensitive credentials.
• Tenant Isolation — Each customer's data is stored in a completely separate MariaDB schema with no cross-tenant access possible.
• Continuous Monitoring — All security-relevant events are logged and monitored for anomalies.

2. Infrastructure Security

2.1 Server Environment

The Service runs on AlmaLinux 9.x (RHEL-family) with Apache (httpd) and PHP-FPM. The architecture uses a dynamic process pool (up to 50 workers), OPcache (128MB), and Unix socket communication for high throughput with strict security controls at every layer.

2.2 Security Headers

Every HTTP response includes security headers enforced at the middleware level:

• Strict-Transport-Security (HSTS) — Forces HTTPS connections with a 1-year max-age and includeSubDomains directive.
• Content-Security-Policy (CSP) — Nonce-based script-src to prevent XSS. Restricts resource loading to trusted origins.
• X-Content-Type-Options: nosniff — Prevents MIME-type sniffing attacks.
• X-Frame-Options: DENY — Prevents clickjacking by blocking iframe embedding.
• Referrer-Policy: strict-origin-when-cross-origin — Limits referrer information leakage.
• Permissions-Policy — Restricts access to browser APIs (camera, microphone, geolocation) that the application does not use.

2.3 CORS Policy

Cross-Origin Resource Sharing is strictly configured to allow requests only from authorized frontend origins. No wildcards in production. Credentials are transmitted only to trusted origins. Rejected origins are logged at warning level.

2.4 Network Security

All traffic is encrypted using TLS 1.2 or higher. Older TLS versions and weak cipher suites are disabled. HTTP requests are automatically redirected to HTTPS. SSL certificates are managed and auto-renewed.

3. Data Encryption

3.1 Encryption in Transit

All client-server communication is encrypted using TLS 1.2+. This includes: browser-to-API connections, API-to-ERPRev data synchronization, API-to-AI insight requests (SSE streaming), and webhook delivery to customer-configured endpoints.

3.2 Encryption at Rest

Sensitive data is encrypted before being written to the database:

• ERPRev API Credentials — Account URLs, API keys, and API secrets are encrypted using AES-256-GCM (256-bit key, authenticated encryption with associated data). The encryption key is deterministically derived from a secure environment variable (JWT_SECRET) and is never stored alongside the encrypted data. Credentials are decrypted only in memory at the moment of use and are never logged or cached in plaintext.
• User Passwords — Hashed using bcrypt via PHP's password_hash() with PASSWORD_BCRYPT and automatically generated unique salts. Password hashes are one-way and cannot be reversed.
• 2FA Secrets — TOTP secrets (via spomky-labs/otphp) are encrypted at rest and decrypted only during authentication verification.
• Recovery Codes — Two-factor authentication recovery codes are hashed before storage. Used codes are invalidated immediately upon use.

3.3 Key Management

Encryption keys are stored in environment variables on the server and are never committed to source control, logged, or exposed via API responses. Key rotation procedures are documented and can be performed without service downtime.

4. Authentication & Access Control

4.1 JWT Authentication

User sessions are managed using JSON Web Tokens (JWT) via firebase/php-jwt with the following security properties:

• Tokens are signed using HMAC-SHA256 with a cryptographically random secret.
• Tokens have a configurable expiration (default: 8 hours).
• Tokens are delivered exclusively via HttpOnly cookies with Secure and SameSite=Lax flags set. This prevents JavaScript access to the token.
• Tokens are never stored in localStorage or sessionStorage.
• Token validation occurs on every API request via AuthMiddleware.

4.2 Two-Factor Authentication (2FA)

We support TOTP-based two-factor authentication compatible with standard authenticator apps (Google Authenticator, Authy, Microsoft Authenticator, 1Password, etc.):

• 2FA enrollment generates a unique secret and displays a QR code for easy scanning.
• A set of one-time recovery codes is provided at enrollment for account recovery.
• After entering their password, users with 2FA enabled must provide a valid 6-digit TOTP code.
• Administrators can require 2FA for all users in their organization.

4.3 CSRF Protection

All state-changing requests (POST, PUT, PATCH, DELETE) require a valid CSRF token using the double-submit cookie pattern. Tokens are 64-character hex values generated from random_bytes(32) and validated via timing-safe comparison (hash_equals()).

4.4 Role-Based Access Control (RBAC)

Beyond role-level access, administrators can configure per-tab access, per-feature permissions (Data View, Intelligence Suite, Export, AI Insights), and department assignment.

5. API Security

5.1 Rate Limiting

All API endpoints are protected by IP-based and per-user rate limiting. Authentication endpoints have strict limits. Sensitive endpoints (settings, password, 2FA) have per-user limits of 15 req/min. Rate limit responses include Retry-After headers.

5.2 Input Validation

All API inputs are validated using a centralized Validator class with 10+ built-in rules (required, email, string, integer, min/max, in, regex, uuid). Validation failures return typed ValidationException with per-field error messages.

5.3 SQL Injection Prevention

All database interactions use PDO with parameterized queries. No raw SQL strings with user-supplied values are used anywhere in the codebase. The MariaDB driver provides connection pooling and proper charset enforcement (utf8mb4).

5.4 ERPRev API Communication

• All API calls to ERPRev are made over HTTPS via cURL.
• Credentials are decrypted in memory only at the moment of the API call.
• The Service operates in a read-only capacity — we never modify data in your ERPRev system.
• Concurrent API calls limited to 4 via flock() semaphore to respect ERPRev rate limits.
• Auto-retry on HTTP 429 with exponential backoff (1s, 2s, 4s).

6. Data Isolation

6.1 Per-Tenant MariaDB Schemas

Each customer's business data is stored in a completely separate MariaDB schema (tenant_{org_id_prefix}). This architecture provides the strongest form of data isolation:

• Schema Separation — Each tenant has its own database schema with 24 dedicated tables. No shared data tables between tenants.
• No Cross-Tenant Queries — Database connections are scoped to the active tenant schema via TenantManager. It is architecturally impossible for a query to access another tenant's data.
• Independent Lifecycle — Each tenant schema can be independently backed up, restored, migrated, or deleted without affecting other tenants.
• Per-Request Context — TenantManager holds per-request tenant context and never returns the default client when tenant context is active.

6.2 Three-Tier Caching

• Tier 1: Memcached — Per-tab cached data with TTL, scoped to the authenticated user's tenant.
• Tier 2: MariaDB Cache — Database-level cache in the tenant's isolated schema with configurable retention.
• Tier 3: ERPRev API — Live data from your ERPRev system, fetched on cache miss or during scheduled sync.

7. Application Security

7.1 Frontend Security

• Vanilla JavaScript with explicit HTML escaping via escapeHtml() for all user-rendered content.
• No use of innerHTML with unsanitized data.
• Authentication tokens stored in HttpOnly cookies, not in JavaScript-accessible storage.
• Content Security Policy with nonce-based script-src.
• Error boundary component prevents cascading UI failures.

7.2 Dependency Management

We maintain only 5 Composer dependencies (firebase/php-jwt, defuse/php-encryption, spomky-labs/otphp, phpmailer/phpmailer, stripe/stripe-php). This minimal footprint drastically reduces supply chain attack surface. No JavaScript build dependencies — Tailwind CSS is loaded via CDN.

7.3 Session Management

• All active sessions listed with device type, IP address, and last activity.
• Users can revoke any individual session or all sessions except the current one.
• Administrators can revoke sessions for any user in their organization.
• Password changes automatically invalidate all other active sessions.

8. Monitoring & Incident Response

8.1 Structured Logging

All security-relevant events are logged in JSON lines format with daily rotation. 50+ event types tracked via ActivityTracker including: login attempts, 2FA events, password changes, ERPRev credential updates, user management actions, data exports, and session events. PSR-3 compatible log levels with severity-based routing (warning for 4xx, error for 5xx).

8.2 Health Monitoring

8-point healthcheck runs every 5 minutes: PHP-FPM, Apache, MariaDB, Memcached, API connectivity, database accessibility, disk space, and cron job status. Automated alerts on failure.

8.3 Incident Response

1. Detection — Automated monitoring and alerts for anomalous activity patterns.
2. Containment — Immediate isolation of affected systems and revocation of compromised credentials.
3. Investigation — Root cause analysis using audit logs and system telemetry.
4. Notification — Affected customers notified within 72 hours of confirmed incidents, per GDPR requirements.
5. Remediation — Patching the vulnerability and implementing measures to prevent recurrence.
6. Post-Mortem — Documented incident report with lessons learned and action items.

9. Compliance & Standards

• OWASP Top 10 — Our development practices address all OWASP Top 10 risks, including injection, broken authentication, sensitive data exposure, XSS, and security misconfiguration.
• GDPR — Data minimization, right to erasure, data portability, and breach notification.
• POPIA — Lawful processing, purpose limitation, and data subject rights per South Africa's Protection of Personal Information Act.
• PCI-DSS — We do not store, process, or transmit cardholder data directly. Payment processing is delegated entirely to PCI-DSS certified processors (Stripe, Paystack).
• SOC 2 Type II — Our security controls are designed to meet SOC 2 trust service criteria for security, availability, and confidentiality.

10. Vulnerability Reporting

We value the work of security researchers and welcome responsible disclosure.

10.1 Responsible Disclosure Guidelines

• Provide sufficient detail for us to reproduce and understand the vulnerability.
• Allow us a reasonable timeframe (90 days) to address the vulnerability before public disclosure.
• Do not access, modify, or delete data belonging to other users during your research.
• Do not perform denial-of-service testing against production systems.

10.2 Our Commitment

• We will acknowledge receipt within 2 business days.
• We will provide an initial assessment within 5 business days.
• We will not pursue legal action against researchers who comply with these guidelines.
• We will credit researchers (with consent) in our security advisories.

11. Security Updates

We review and update our security practices at least quarterly, and perform penetration testing at least annually. When we make material changes, we update this page, notify affected customers, and publish security advisories. Results of penetration tests are available to enterprise customers under NDA upon request.

12. Contact

• Security Team: security@erprevpromax.com
• Privacy Inquiries: privacy@erprevpromax.com
• General Support: support@erprevpromax.com
• Website: www.erprevpromax.com