Security & Secrets

ReAPI provides zero-knowledge encryption for sensitive credentials used in API testing. Your secrets are encrypted client-side before reaching our servers, ensuring maximum security for your team’s API keys, passwords, and tokens.

Subscription Feature: Secrets management is available to paid users only.

Security Capabilities

What You Get

• Zero-Knowledge Encryption: Secrets encrypted in your browser using AES-256-GCM before being sent to ReAPI servers
• Two Security Modes: Choose between plaintext (convenience) or encrypted (security) based on your environment
• Biometric Unlock: Use Touch ID, Face ID, or Windows Hello for fast, secure access
• Access Control: Restrict who can view and use encrypted secrets with authorization lists
• Compliance Ready: Meets SOC 2, GDPR, HIPAA, and PCI DSS requirements

How Secure?

ReAPI uses industry-standard encryption:

Zero-knowledge architecture: Even if our database is compromised, attackers cannot decrypt your secrets without your master password.

Quick Comparison

Secrets vs Variables

Rule of thumb: If you wouldn’t want it in a screenshot or database dump, use a secret.

Plaintext vs Encrypted Mode

ReAPI supports two storage modes for secrets:

When to use each mode:

• Plaintext: Development API keys, test databases, non-production environments
• Encrypted: Production credentials, customer data access, payment APIs, OAuth secrets

Quick Start

Get started with secrets in 2 minutes.

Option 1: Plaintext Secrets (Development)

Perfect for development and test environments:

1. Go to Environments → Select your Variable Group
2. Click Secrets section → Create Plaintext Secrets
3. Add your secrets:

dev_api_key: dev_key_12345
test_db_password: test_password

4. Use in tests with {{$secrets.dev_api_key}}

✅ No unlock needed — Works like regular variables, ready to use immediately.

Option 2: Encrypted Secrets (Production)

For production credentials that need protection:

1. One-time setup: Go to Project Settings → Security → Set master password
2. Open your Variable Group → Secrets section
3. Click Enable Encryption → Enter your master password
4. Add secrets (same syntax as plaintext)
5. Use in tests with {{$secrets.api_key}}

🔒 Unlock required — Secrets are encrypted and masked (••••••) until you enter password or use biometric unlock.

Optional: Register your device for biometric unlock (Touch ID/Face ID) in Project Settings → Security → Register Device.

Using Secrets in Tests

Both modes use the same syntax:

# API Request Headers
Authorization: Bearer {{$secrets.api_key}}
 
# Request Body
{
  "password": "{{$secrets.user_password}}"
}
 
# JSONata expressions
$secrets.ENVIRONMENT = "production"

Variable Group Level Configuration

Important: Secrets configuration is at the Variable Group level, not project-wide. This allows flexibility:

• Dev VarGroup: Plaintext mode → Fast access for development
• Staging VarGroup: Encrypted with 4-hour cache → Balanced for testing
• Production VarGroup: Encrypted with 0-second cache → Maximum security

Each Variable Group can have its own:

• Encryption mode (plaintext or encrypted)
• Cache duration (if encrypted)
• Secrets inheritance from parent groups

Choosing Your Security Level

For encrypted Variable Groups, configure the secrets cache duration to balance security and convenience:

For absolute security: Use CLI secrets injection where secrets never reach ReAPI servers. Perfect for production CI/CD pipelines.

Recommendation: Use biometric unlock (Touch ID/Face ID) with 0-second cache for production—you get maximum security without typing passwords repeatedly.

Mask Sensitive Data in Test Results

Beyond encrypting secrets in storage, ReAPI can automatically mask sensitive data in test execution results and request/response viewers.

What it does: Replaces sensitive values with *** in the UI, protecting:

• Authorization headers
• API keys in requests/responses
• Passwords in request bodies
• Tokens and secrets in context

How to configure:

1. Go to Project Settings → Security → Sensitive Data Masking
2. Add path patterns (one per line):

request.headers.Authorization
request.body.password
response.body.**.access_token
context.secrets.**

3. Click Load Defaults for 33 pre-configured patterns
4. Toggle mask/unmask in test results viewer with the eye icon 👁️

Pattern examples:

• request.headers.Authorization — Exact path
• request.body.**.password — Any depth with **
• users[*].apiKey — All array items with [*]

📘 For complete masking documentation, see the Sensitive Data Masking Guide.

📘 For secrets encryption, advanced features, troubleshooting, and best practices, see the Secrets Management Guide.

Common Use Cases

Multi-Environment Strategy

Set up different security levels for each environment:

• Development: Plaintext mode → Fast iteration, no unlock friction
• Staging: Encrypted mode with 1-4 hour cache → Balance of security and usability
• Production: Encrypted mode with 0-second cache → Maximum security, unlock every time

Same code works everywhere: All use {{$secrets.xxx}} syntax.

Team Collaboration

Control access with Variable Group permissions:

• New team members: Add to Variable Group with appropriate permissions
• Biometric registration: Admins can help team members register devices without sharing passwords
• Access revocation: Remove from Variable Group when team members leave

Switching Security Modes

You can enable or disable encryption as your needs change:

• Enable encryption: Add master password protection to existing plaintext secrets
• Disable encryption: Convert encrypted secrets back to plaintext (for dev-only use)

📘 See detailed scenarios, team workflows, and step-by-step guides in the Secrets Management Guide.

Understanding Security Boundaries

What Encrypted Mode Protects ✅

Storage Security (Data at Rest):

• Database breach: Secrets remain encrypted in storage
• ReAPI employee access: Cannot view secrets in database
• Backup/log leaks: Secrets stored as ciphertext
• Unauthorized access: Cannot read plaintext without password

Zero-knowledge architecture: Even if ReAPI’s servers are compromised, attackers cannot decrypt your secrets.

What Encrypted Mode Does NOT Protect ❌

Execution Security (Data in Use):

Once an authorized user unlocks secrets and runs a test:

• Secrets are visible in HTTP request headers/body
• Secrets may appear in response data
• Secrets visible in browser DevTools (Network tab)
• Secrets stored in browser memory during execution

Key Insight: Encrypted mode prevents unauthorized storage access, but authorized users can see secrets during test execution. This is by design—tests need plaintext secrets to authenticate with target APIs.

Additional Security Boundaries

📘 For detailed threat models, attack scenarios, and security hardening, see the Secrets Management Guide.

Advanced Features

For production deployments and enterprise security needs, ReAPI offers:

CLI Secrets Injection

Inject secrets at runtime from your own vault (AWS Secrets Manager, HashiCorp Vault):

# Secrets never stored in ReAPI cloud
reapi run my-test-suite --secrets-file ./prod-secrets.json

Benefits: Zero-knowledge extended to deployments, instant rotation without re-deployment.

Secrets Authorization Control

Restrict which users can unlock and use encrypted Variable Groups:

• Production secrets: Only senior engineers can access
• Compliance: Separate dev team from production credentials
• API-enforced: Backend validates authorization on every request

Additional Security Features

• Biometric unlock: Touch ID, Face ID, Windows Hello
• Cache control: Configure per-environment (0 seconds to session-scoped)
• Device management: Register multiple devices, revoke access anytime
• Secrets inheritance: Share common secrets, override per-environment

📘 For complete documentation on advanced features, see the Secrets Management Guide.

Best Practices Summary

DO ✅

• Choose the right mode: Plaintext for dev, encrypted for production
• Use strong passwords: 20+ characters, stored in password manager
• Configure cache wisely: 0 seconds for production, hours for development
• Rotate regularly: Change secrets every 90 days or when team members leave
• Enable biometric unlock: Convenient and secure for daily use
• Control access: Use Variable Group permissions and authorization lists
• Use HTTPS: Always test against secure endpoints

DON’T ❌

• Don’t use weak passwords: Avoid common words or predictable patterns
• Don’t share passwords: Use biometric device registration instead
• Don’t store non-secrets: Use regular variables for non-sensitive config
• Don’t delay revocation: Remove access immediately when team members leave
• Don’t ignore security boundaries: Understand what encrypted mode protects

📘 For detailed best practices, compliance guidance, and troubleshooting, see the Secrets Management Guide.

Compliance Support

ReAPI’s encrypted mode supports compliance with SOC 2, GDPR, HIPAA, and PCI DSS:

• Encryption: AES-256-GCM (NIST FIPS 140-2)
• Key derivation: PBKDF2-SHA256 (NIST SP 800-132)
• Biometric: WebAuthn Level 2 (W3C specification)
• Transport: TLS 1.3 (RFC 8446)

Important: Always use encrypted mode for regulated credentials. Plaintext mode does not meet encryption requirements for compliance standards.

Questions? Contact security@reapi.com

Next Steps

Now that you understand ReAPI’s security capabilities, dive deeper:

1. Secrets Management Guide - Complete setup, troubleshooting, and advanced features
2. Variable Groups - Organize secrets across environments
3. CLI Usage - Integrate with CI/CD pipelines
4. Team Permissions - Control access across your organization

Need help? Contact security@reapi.com or docs@reapi.com