Security

Authentication

Euriqa supports two authentication methods. Both enforce the same authorization rules.

User Authentication (Dashboard)

• Email/password sign-up with mandatory email verification
• Secure password reset flow via email with time-limited tokens
• Session-based authentication managed by Supabase Auth
• OAuth support for third-party login providers (via Supabase callback)
• Automatic session refresh with secure HTTP-only cookies

API Key Authentication (CI/CD)

API keys are the recommended authentication method for CI/CD pipelines and programmatic access.

• Format: euriqa_sk_... — prefixed for easy identification
• Scoped to a specific user, team, and project — cannot access other projects
• Minimum 16 characters with placeholder rejection (rejects values like your-api-key-here)
• Soft-delete deactivation — keys can be deactivated without permanent deletion
• Optional expiration dates for temporary or contractor access
• Last-used timestamp tracking for auditing
• Full key value shown only once at creation — store securely

curl -H "X-API-Key: euriqa_sk_..." https://app.euriqa.dev/api/runs

Dual Authentication Support

All API endpoints accept both session cookies (browser) and API key headers (CI/CD). The server attempts session authentication first, then falls back to API key. Both methods enforce identical authorization rules — there is no privilege difference between authentication methods.

Authorization & Access Control

Row-Level Security (RLS)

All data access in Euriqa is controlled at the PostgreSQL database level using Supabase Row-Level Security policies. This means authorization is enforced by the database engine itself — not by application code. Even if an application-level bug were introduced, the database would still reject unauthorized access.

• User-scoped — Users can only access their own profile, preferences, and account data
• Team-scoped — Users can only access teams they are members of
• Project-scoped — Test runs, results, artifacts, and analytics are isolated per project
• Role-based — Actions are gated by team role

Role-Based Permissions

Every team member has one of four roles. Permissions are enforced at both the API and database level.

Viewer seats are free and unlimited on every plan. Only Owner, Admin, and Member roles count toward seat limits.

Data Security

Artifact Storage

All test artifacts (screenshots, videos, Playwright traces, HTML reports) are stored in private cloud storage. No artifact is publicly accessible. Access is granted exclusively through signed URLs.

• Signed URLs — Time-limited (1-hour expiration by default). Generated on demand when a team member requests access.
• Project-scoped — Only team members with access to the project can view its artifacts.
• No permanent public URLs — URLs expire and cannot be reused. New URLs are generated for each access request.
• Storage isolation — Artifacts are organized by project and run: {project_id}/{run_id}/{type}/{filename}

File Upload Security

Multiple layers of validation protect against malicious file uploads:

• Path traversal prevention — File paths are validated against .., null bytes, and URL-encoded variants
• Extension whitelisting — Only allowed file extensions are accepted per artifact type (e.g., screenshots: .png .jpg .webp, traces: .zip)
• MIME type validation — Uploaded file MIME type must match the declared artifact type
• File size limits — Enforced per artifact type (screenshots: 10 MB, videos: 100 MB, traces: 100 MB)
• Working directory confinement — The SDK cannot access files outside the project directory

Encryption

• In transit — HTTPS/TLS required for all API communication. HTTP connections are rejected.
• At rest — Database managed by Supabase with encrypted storage and automatic backups.
• Environment variables — Encrypted using dotenvx. Never committed to source control.

API Security

Request Validation

Every API request is validated using Zod schemas before processing. Invalid requests are rejected with descriptive error messages. This prevents injection attacks, unexpected data shapes, and type confusion.

Rate Limiting

All API endpoints are rate-limited to prevent abuse and ensure fair usage:

Rate limits are per IP address. Exceeding limits returns 429 Too Many Requests.

Sensitive Data Handling

• API keys are masked in all log output (only last 4 characters shown)
• Sensitive data is sanitized before error reporting
• Full API key value is returned only once at creation time
• Passwords are hashed — never stored in plain text

SDK & Reporter Security

The @euriqa/euriqa-playwright reporter runs in your CI environment. It is designed with the principle of least privilege:

• API key validation — Validates the API key format and rejects placeholder values before making any network call
• File path normalization — All file paths are normalized and validated before reading
• Directory confinement— The reporter cannot access files outside the project's working directory
• Extension whitelisting — Only known safe file extensions can be uploaded
• No sensitive data in output — API keys and tokens are never written to stdout/stderr
• Debug mode masking — Even with debug: true, sensitive data is automatically masked in output

Webhook Security

Webhooks deliver event notifications to your endpoints. Euriqa protects webhook delivery with:

• HTTPS required — Webhook URLs must use HTTPS. HTTP endpoints are rejected.
• No private networks — Webhook URLs pointing to private IP ranges (localhost, 10.x.x.x, 192.168.x.x, 172.16-31.x.x) are rejected to prevent SSRF attacks.
• Signature verification — Optionally configure a webhook secret. Euriqa generates an HMAC-SHA256 signature for each delivery, allowing your endpoint to verify the payload originated from Euriqa.
• Custom headers — Add authentication headers to webhook requests for endpoint-level access control.

import crypto from 'crypto';

function verifyWebhook(payload: string, signature: string, secret: string): boolean {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}

Infrastructure

• Database — PostgreSQL managed by Supabase with automatic backups, point-in-time recovery, and encrypted storage
• Artifact storage — Supabase Storage with private buckets and signed URL access
• Environment variables — Encrypted with dotenvx. Rotated periodically. Never committed to version control.
• CDN — Static assets and artifact delivery backed by CDN for performance and DDoS mitigation
• Monitoring — Application and infrastructure monitoring with alerting for anomalous access patterns

Compliance & Data Governance

Data Retention

Data retention is configurable per project. When the retention period expires, test runs, results, and associated artifacts are permanently deleted.

Data Isolation

• No test data is shared between teams — complete tenant isolation
• No data is shared between projects within a team — project-level isolation
• API keys are scoped to a single project and cannot access other projects
• Database queries are filtered by RLS policies at every level

Audit Trail

• API key usage is tracked with last-used timestamps
• All data modifications are timestamped with created_at and updated_at fields
• Webhook deliveries are logged
• Team membership changes are recorded

GDPR & Privacy

• Euriqa collects only the data necessary to provide the service (test results, artifacts, git metadata)
• Users can delete their account and associated data
• Data retention is configurable — set it to the minimum your team needs
• No test data is used for training, analytics, or any purpose beyond providing the service to the team that owns it

Compliance Roadmap

• SOC 2 Type II — In progress
• GDPR compliance — Current practices align with GDPR requirements
• On-premise deployment — Available for Enterprise plans

Security Best Practices

Recommendations for keeping your Euriqa integration secure:

1. Store API keys as CI secrets— Never commit keys to source control. Use your CI provider's secret management (GitHub Actions Secrets, GitLab CI Variables, etc.).
2. Use one key per environment— Create separate API keys for staging and production. Name them descriptively (e.g., "GitHub Actions — staging").
3. Rotate keys periodically — Deactivate old keys and create new ones on a regular cadence.
4. Set expiration dates — For temporary access (contractors, trial integrations), set an expiration date on the API key.
5. Use the minimum role needed — Assign Viewer to people who only need to see results. Reserve Admin for people who manage settings.
6. Enable webhook signatures — Configure a webhook secret and verify HMAC signatures on your receiving endpoint.
7. Review API key usage — Periodically check last-used timestamps and deactivate unused keys.

Reporting Security Issues

If you discover a security vulnerability in Euriqa, please report it responsibly:

• Email security@euriqa.dev
• Include a description of the vulnerability, steps to reproduce, and potential impact
• We will acknowledge your report within 24 hours
• We will provide a timeline for a fix and keep you updated
• We do not pursue legal action against security researchers acting in good faith