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

This skill helps secure FireCrawl usage by guiding secret storage, rotation, and least-privilege access with audit-ready configurations.

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

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

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

# FireCrawl Security Basics

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

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

## Instructions

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

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

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

# 3. Verify new key works
curl -H "Authorization: Bearer ${FIRECRAWL_API_KEY}" \
  https://api.firecrawl.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 FireCrawlClient({
    apiKey: process.env.FIRECRAWL_READ_KEY,
  }),
  writer: new FireCrawlClient({
    apiKey: process.env.FIRECRAWL_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 FireCrawl analytics
  await firecrawlClient.track('audit', log);

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

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

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

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

Overview

This skill applies FireCrawl security best practices for API keys, tokens, webhooks, and access control. It focuses on secure storage, secret rotation, least-privilege scope management, and audit logging to reduce risk and meet compliance needs.

How this skill works

The skill inspects configuration patterns and provides actionable steps: store secrets in environment variables and .gitignore, rotate keys safely, split service accounts by role, verify webhook signatures, and enable audit logging. It guides detection and mitigation of common failures such as exposed keys, excessive scopes, and missing rotation schedules.

When to use it

  • When storing or deploying FireCrawl API keys and secrets
  • When implementing least-privilege access across environments
  • During security audits or pre-production reviews
  • When adding or rotating service keys or webhooks
  • When enabling or validating audit logging and compliance

Best practices

  • Never commit .env files or API keys to version control; add .env and related files to .gitignore
  • Use environment-specific keys: separate keys for development, staging, and production
  • Apply least privilege: restrict scopes per environment and limit write permissions in non-production
  • Implement key rotation: provision new key, test, then revoke the old key
  • Validate webhooks with HMAC timing-safe comparisons to prevent tampering
  • Record audit entries for key use and admin actions to maintain traceability

Example use cases

  • Store FIRECRAWL_API_KEY in a .env file excluded from git and load via environment variables in CI/CD
  • Create reader and writer service accounts with distinct keys and limited scopes
  • Rotate a compromised key: generate new key in dashboard, update env, verify with health endpoint, then revoke old key
  • Validate webhook payloads using HMAC-SHA256 and timing-safe comparison before processing
  • Emit audit logs to FireCrawl analytics and local secure storage for compliance and incident investigation

FAQ

How do I rotate a FireCrawl API key without downtime?

Generate the new key in the FireCrawl dashboard, update the environment variable in a controlled deploy or configuration store, verify the service against the health endpoint, then revoke the old key once verification passes.

What scopes should production keys have?

Production keys should have only the scopes required for the service to operate. Avoid broad read:* or write:* permissions; audit each required endpoint and assign minimal scopes accordingly.