🔒 Platform Security

All three domains use HTTPS with HTTP Strict Transport Security (HSTS) configured with max-age of 31536000 seconds (one year), includeSubDomains, and the preload directive. This means browsers that have visited any VAU0 domain will refuse to connect over plain HTTP in the future. The preload directive submits the domains to browser vendor HSTS preload lists, so even first-time visitors are protected. TLS certificates are provisioned automatically and renewed before expiration. All HTTP requests receive a 301 redirect to HTTPS — there is no way to access any VAU0 service over an unencrypted connection.

CSP headers on every response prevent cross-site scripting (XSS) by whitelisting exactly which domains can serve scripts, stylesheets, images, fonts, and API connections. Inline scripts are blocked unless they match a nonce or hash. This eliminates the most common web attack vector. In addition to CSP, every response includes Referrer-Policy (strict-origin-when-cross-origin) to limit referrer data leakage, and Permissions-Policy to disable browser APIs that VAU0 does not use (geolocation, microphone, camera, payment). These headers are tested automatically on every deployment.

Session cookies are flagged Secure (HTTPS only), HttpOnly (inaccessible to JavaScript), and SameSite (prevents cross-site request forgery). The SESSION_SECRET used for cookie signing is a 64-character cryptographically random string. Sessions expire automatically after a configurable period of inactivity. On logout, the session is destroyed server-side — not just cleared from the browser. Session IDs are regenerated on privilege changes (login, role change) to prevent session fixation attacks.

All passwords are hashed with bcrypt at cost factor 12 — deliberately slow to resist brute-force attacks. No plaintext passwords are stored anywhere in the system: not in the database, not in logs, not in error messages, not in backups. Password reset tokens are time-limited (expire after use or after a short window) and are single-use. Minimum password strength is enforced at registration and on password change. The system rejects passwords that appear in known breach databases.

Three completely separate session contexts exist: portal users (drivers and internal staff), carrier users (company administrators), and ERETH ELD administrators. Each context uses its own session namespace, its own user table, and its own authentication middleware. There is no code path that allows a user in one context to escalate to another. Even if an attacker compromises a session cookie from one context, it is cryptographically invalid in the others. Role-based middleware checks run on every request, not just at login.

Every sensitive action is logged with full context: the user who performed it, what action was taken, which record was affected, the timestamp, and the originating IP address. Audit logs are append-only — no user, including administrators, can delete or modify log entries. This provides a tamper-proof record for compliance audits, incident investigation, and accountability. Logs cover authentication events, data access, role changes, document operations, and configuration modifications.

The main session context for VAU0 Portal. Uses the standard connect.sid session cookie. User records live in the users table with bcrypt-hashed passwords. Supports both local authentication and OAuth (Google, Microsoft). Role-based middleware enforces access at the route level — admin, recruiter, dispatcher, driver, and viewer roles each have distinct permissions. Session data includes user ID, role, company association, and last-activity timestamp. Sessions expire after 24 hours of inactivity by default.

A completely separate session namespace stored in req.session.carrier. User records live in the company_users table — a different table from portal users. Authentication is independent: a carrier user logging in does not create or affect any portal session. Carrier sessions are scoped to a single company — a user cannot access data from another carrier even if they guess the URL. Company-level permissions (owner, admin, viewer) control what each carrier user can see and modify within their own organization.

The ERETH ELD administration panel has its own dedicated authentication system. Admin users are stored separately and authenticate through a dedicated login page. This context handles FMCSA audit access, ELD device management, driver log review, and compliance reporting. ELD admin sessions have the strictest timeout policies — 15 minutes of inactivity triggers automatic logout. All actions in this context are logged to a dedicated audit trail that meets FMCSA Part 395 record-keeping requirements.

All session cookies across all three contexts share these security attributes:

The authentication process for each context follows the same secure pattern:

Social Security Numbers are never stored in the VAU0 database. Applications that collect SSN transmit the value directly to the background check provider over an encrypted channel and discard it immediately. CDL numbers are encrypted at rest using AES-256. Driver addresses, dates of birth, and medical certificate data are stored in the database with role-based access controls — only users with recruiter or admin roles can view PII fields. API endpoints that return driver data redact sensitive fields by default; full data requires explicit permission scope.

Rate confirmations, invoices, and settlement data are encrypted in transit and at rest. Access is restricted by role: dispatchers can view rate cons for their assigned loads, but only accounting-role users can see settlement amounts and payment details. Financial documents are stored with signed URLs that expire after a short window — there are no permanent public links to financial documents. All financial data access is logged to the audit trail with the requesting user, timestamp, and document identifier.

ELD data includes driver hours of service, vehicle location, engine diagnostics, and driving events. This data is retained in compliance with FMCSA Part 395 requirements (minimum 6 months for driver logs). Driver consent is obtained during onboarding before any telematics data is collected. Location data is stored with appropriate granularity for compliance purposes but is not used for non-compliance tracking. ELD data access is restricted to the driver (their own data), their carrier admin, and FMCSA auditors (through the official audit transfer mechanism).

Uploaded documents (CDL images, medical certificates, MVR reports, insurance certificates, W-9 forms) are stored in access-controlled storage. Each document is associated with a specific user and company. Access requires both authentication and authorization — a valid session plus the correct role for the document type. Documents are served through signed URLs that expire after 15 minutes. Direct storage access is blocked at the infrastructure level. Document deletion follows retention policy rules — compliance documents cannot be deleted before their retention period expires.

All user input is validated and sanitized on the server side before processing. Email addresses, phone numbers, dates, and numeric fields are validated against strict patterns. File uploads are checked for type, size, and content. Malformed input is rejected with a generic error — no internal details are exposed.

Production error responses never include stack traces, database queries, file paths, or internal system information. Detailed errors are logged server-side for debugging but the client receives only a generic message and an error reference ID. This prevents information disclosure that could help an attacker map the system.

API endpoints are rate-limited per IP address and per authenticated user. Login endpoints have stricter limits to prevent credential stuffing. Rate limit responses include Retry-After headers. Persistent abuse triggers automatic IP blocking for a configurable cooldown period. Rate limit configurations are tuned per endpoint based on expected usage patterns.

Driver Qualification Files with FMCSA-compliant document retention. Security controls ensure documents cannot be accessed by unauthorized users or deleted before retention periods expire.

Electronic logging device platform with its own dedicated security context. FMCSA Part 395 compliant data handling, driver consent management, and secure audit transfer capabilities.

Business intelligence and reporting with role-scoped data access. Users only see analytics for data they are authorized to view. Export controls prevent unauthorized data extraction.