Security & Compliance

At Trackr, we treat data security and privacy as foundational pillars of the application. Job seekers trust the platform with highly sensitive personal information, including resumes, salary expectations, and private interview notes. This document outlines the security mechanisms engineered into Trackr to protect against vulnerabilities and ensure compliance with major frameworks (SOC2, GDPR).

Authentication

Trackr uses NextAuth.js (Auth.js) for robust, secure session management. We support multiple authentication strategies:

1. Email & Password: Passwords are never stored in plaintext. They are hashed using Argon2id, the winner of the Password Hashing Competition. Argon2id is memory-hard, providing strong resistance against GPU cracking attacks.
2. OAuth 2.0 (SSO): We support Google, GitHub, and Microsoft Entra ID (Azure AD). When using OAuth, Trackr only requests the minimum necessary scopes (email and profile).
3. Enterprise SAML: For enterprise deployments, Trackr integrates with identity providers like Okta and Ping Identity via SAML 2.0, allowing organizations to enforce their own MFA and password rotation policies.

Session Management

Sessions are managed via HTTP-only, secure, SameSite=Lax cookies. JWTs (JSON Web Tokens) are encrypted using JWE (JSON Web Encryption) with A256GCM. Tokens have a short lifespan (1 hour) and are automatically refreshed seamlessly in the background, minimizing the window of opportunity if a token is somehow compromised.

Role-Based Access Control (RBAC)

Trackr implements strict RBAC to ensure users only access what they are permitted to.

Granular Roles

• Owner: Full administrative control over the workspace, billing, and member management.
• Admin: Can manage workspace settings, invite users, and configure webhooks.
• Member: Standard user. Can create and manage their own job applications and view shared team data (if team features are enabled).
• Viewer: Read-only access to dashboards and analytics.

Implementation

Authorization checks happen at three levels to prevent privilege escalation:

1. UI Layer: The frontend hides buttons and routes based on the user's role. (This is for UX, not security).
2. API Route/Middleware Level: Every Next.js API route and Server Action verifies the session and the user's role before processing the payload.
3. Database Level (RLS): Row Level Security policies in PostgreSQL act as the ultimate fail-safe. Even if a flaw exists in the API logic, the database engine will reject the query if the user does not have permission to touch the data.

Data Encryption

Encryption in Transit

All data moving between the client and Trackr servers, as well as between internal microservices, is encrypted using TLS 1.2 or TLS 1.3. Non-HTTPS connections are automatically redirected to HTTPS. HSTS (HTTP Strict Transport Security) is enforced with a long max-age.

Encryption at Rest

• Database: When self-hosted on AWS RDS, Amazon EBS volume encryption using AES-256 is enabled by default.
• Object Storage: S3 buckets storing resumes and avatars enforce SSE-S3 (Server-Side Encryption with Amazon S3 managed keys) or SSE-KMS.
• Application Level Encryption: Highly sensitive fields (such as third-party API keys stored by users for integrations) are encrypted at the application level using AES-256-GCM before being written to the database. The encryption keys are managed via a Key Management Service (AWS KMS or HashiCorp Vault).

Secrets Management

Hardcoding secrets is strictly prohibited. Trackr relies on Environment Variables injected at runtime.

In a production environment, we recommend utilizing a dedicated secrets manager:

• AWS Secrets Manager or AWS Systems Manager Parameter Store
• HashiCorp Vault
• Vercel Environment Variables (if deployed on Vercel)

The application initializes a singleton configuration service on startup that validates the presence and format of all required secrets using Zod, preventing the application from booting in an insecure state.

Rate Limiting and DoS Protection

To protect against brute-force attacks and Denial of Service (DoS) attempts, Trackr implements aggressive rate limiting.

API Rate Limiting

Rate limiting is executed at the Edge (using Vercel Edge Middleware or an Nginx/Cloudflare proxy). We use a sliding window algorithm backed by Redis.

• Global API: 100 requests per 10 seconds per IP.
• Authentication Routes (/api/auth/*): 5 requests per minute per IP to prevent credential stuffing.
• Webhooks/Integrations: 1000 requests per minute per Workspace API Key.

When a limit is breached, the API responds with a 429 Too Many Requests status code and a Retry-After header.

OWASP Top 10 Protections

Trackr is proactively developed to mitigate the OWASP Top 10 vulnerabilities:

• Injection (SQLi/XSS): We use Prisma ORM which utilizes parameterized queries, eliminating SQL injection. React and Next.js automatically sanitize inputs to prevent Cross-Site Scripting (XSS).
• Broken Authentication: Handled securely via NextAuth and Argon2.
• Sensitive Data Exposure: Enforced TLS and encryption at rest.
• Security Misconfiguration: Infrastructure as Code (Terraform) ensures repeatable, secure baseline deployments.
• Cross-Site Request Forgery (CSRF): NextAuth automatically generates and validates CSRF tokens for all state-changing requests.

Vulnerability Scanning & Penetration Testing

• Static Analysis: Our CI/CD pipeline runs npm audit, Snyk, and SonarQube to detect known vulnerabilities in open-source dependencies and code smells on every Pull Request.
• Container Scanning: Docker images are scanned using Trivy before being pushed to the registry.
• Penetration Testing: For our enterprise managed offering, we engage with third-party security firms annually to perform gray-box penetration testing.

Security is an ongoing process. If you discover a vulnerability in Trackr, please refer to our SECURITY.md file in the root repository for instructions on responsible disclosure.