home / skills / jeremylongshore / claude-code-plugins-plus-skills / exa-security-basics

This skill helps secure Exa API keys and enforce least-privilege access with rotation and audit logging.

npx playbooks add skill jeremylongshore/claude-code-plugins-plus-skills --skill exa-security-basics

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.3 KB
---
name: exa-security-basics
description: |
  Apply Exa security best practices for secrets and access control.
  Use when securing API keys, implementing least privilege access,
  or auditing Exa security configuration.
  Trigger with phrases like "exa security", "exa secrets",
  "secure exa", "exa API key security".
allowed-tools: Read, Write, Grep
version: 1.0.0
license: MIT
author: Jeremy Longshore <[email protected]>
---

# Exa Security Basics

## Overview
Security best practices for Exa API keys, tokens, and access control.

## Prerequisites
- Exa SDK installed
- Understanding of environment variables
- Access to Exa dashboard

## Instructions

### Step 1: Configure Environment Variables
```bash
# .env (NEVER commit to git)
EXA_API_KEY=sk_live_***
EXA_SECRET=***

# .gitignore
.env
.env.local
.env.*.local
```

### Step 2: Implement Secret Rotation
```bash
# 1. Generate new key in Exa dashboard
# 2. Update environment variable
export EXA_API_KEY="new_key_here"

# 3. Verify new key works
curl -H "Authorization: Bearer ${EXA_API_KEY}" \
  https://api.exa.com/health

# 4. Revoke old key in dashboard
```

### Step 3: Apply Least Privilege
| Environment | Recommended Scopes |
|-------------|-------------------|
| Development | `read:*` |
| Staging | `read:*, write:limited` |
| Production | `Only required scopes` |

## Output
- Secure API key storage
- Environment-specific access controls
- Audit logging enabled

## Error Handling
| Security Issue | Detection | Mitigation |
|----------------|-----------|------------|
| Exposed API key | Git scanning | Rotate immediately |
| Excessive scopes | Audit logs | Reduce permissions |
| Missing rotation | Key age check | Schedule rotation |

## Examples

### Service Account Pattern
```typescript
const clients = {
  reader: new ExaClient({
    apiKey: process.env.EXA_READ_KEY,
  }),
  writer: new ExaClient({
    apiKey: process.env.EXA_WRITE_KEY,
  }),
};
```

### Webhook Signature Verification
```typescript
import crypto from 'crypto';

function verifyWebhookSignature(
  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));
}
```

### Security Checklist
- [ ] API keys in environment variables
- [ ] `.env` files in `.gitignore`
- [ ] Different keys for dev/staging/prod
- [ ] Minimal scopes per environment
- [ ] Webhook signatures validated
- [ ] Audit logging enabled

### Audit Logging
```typescript
interface AuditEntry {
  timestamp: Date;
  action: string;
  userId: string;
  resource: string;
  result: 'success' | 'failure';
  metadata?: Record<string, any>;
}

async function auditLog(entry: Omit<AuditEntry, 'timestamp'>): Promise<void> {
  const log: AuditEntry = { ...entry, timestamp: new Date() };

  // Log to Exa analytics
  await exaClient.track('audit', log);

  // Also log locally for compliance
  console.log('[AUDIT]', JSON.stringify(log));
}

// Usage
await auditLog({
  action: 'exa.api.call',
  userId: currentUser.id,
  resource: '/v1/resource',
  result: 'success',
});
```

## Resources
- [Exa Security Guide](https://docs.exa.com/security)
- [Exa API Scopes](https://docs.exa.com/scopes)

## Next Steps
For production deployment, see `exa-prod-checklist`.

Overview

This skill applies Exa security best practices for API keys, tokens, webhooks, and access control. It guides secure storage, rotation, and least-privilege configuration across environments. Use it to harden Exa integrations and to implement audit logging for compliance.

How this skill works

The skill inspects common secret handling patterns and recommends fixes: environment variable usage, .gitignore rules, and separate keys per environment. It walks through secret rotation steps, scope minimization, webhook signature verification, and audit logging patterns. It also provides detection and mitigation steps for exposed keys and excessive scopes.

When to use it

  • When securing Exa API keys or tokens in apps and CI/CD pipelines
  • When implementing least-privilege access per environment (dev/staging/prod)
  • When auditing Exa-related access, scopes, and audit logs
  • When adding webhook signature verification for inbound requests
  • Before production deployment to confirm secrets and logging are configured

Best practices

  • Never commit .env files; add .env* to .gitignore and use environment variables for secrets
  • Rotate API keys regularly and verify new keys before revoking old ones
  • Create separate service accounts/keys per environment and per role to enforce least privilege
  • Assign minimal scopes required for each environment and operation; audit scopes periodically
  • Validate webhook signatures using timing-safe comparisons to prevent tampering
  • Enable and centralize audit logging for authentication, key changes, and high-risk actions

Example use cases

  • Add EXA_API_KEY and EXA_SECRET to environment variables and ensure .env files are ignored by git
  • Rotate a compromised key: generate new key in dashboard, update env, verify with a health call, then revoke old key
  • Implement service-account pattern with distinct reader/writer keys for isolation of privileges
  • Add webhook signature verification middleware to validate incoming Exa callbacks
  • Instrument auditLog calls on critical actions to record timestamp, userId, resource, and result

FAQ

How often should I rotate Exa API keys?

Rotate keys on a regular cadence based on risk (e.g., every 90 days) and immediately after suspected exposure.

What scopes are safe for development keys?

Use read-only scopes (read:*) for development and add write-limited scopes only when required; never give production-level scopes to dev keys.