Style Stealer API implements multiple layers of security to prevent abuse and protect against malicious actors.

No unauthenticated access is allowed.

Every request to /api/generate must include a valid API key using one of these methods:

Authorization: Bearer sk-your-api-key-here

OR

X-API-Key: sk-your-api-key-here

• Must start with sk-
• Minimum 20 characters
• Stored securely in environment variables
• Multiple keys supported (comma-separated in API_KEYS)

Requests without valid API keys receive:

{
  "success": false,
  "error": "Unauthorized. Valid API key required."
}

HTTP Status: 401 Unauthorized

Maximum: 2048 characters

Prevents spam attacks with extremely long URLs.

{
  "success": false,
  "error": "URL too long (max 2048 characters)"
}

HTTP Status: 400 Bad Request

Maximum: 2048 characters

Prevents spam attacks with extremely long webhook URLs.

{
  "success": false,
  "error": "Webhook URL too long (max 2048 characters)"
}

HTTP Status: 400 Bad Request

Maximum: 10KB

Prevents payload spam and DoS attacks.

{
  "success": false,
  "error": "Request body too large (max 10KB)"
}

HTTP Status: 413 Payload Too Large

All requests must be valid JSON.

{
  "success": false,
  "error": "Invalid JSON in request body"
}

HTTP Status: 400 Bad Request

URLs must be properly formatted and valid.

{
  "success": false,
  "error": "Invalid request: Invalid URL format"
}

HTTP Status: 400 Bad Request

Limit: 100 requests per hour

Each API key can make up to 100 requests per hour.

Response when exceeded:

{
  "success": false,
  "error": "Rate limit exceeded for your API key. Please try again later."
}

HTTP Status: 429 Too Many Requests

Headers:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1705318200
Retry-After: 3600

Limit: 50 requests per minute (across all users)

Protects the service from distributed denial-of-service attacks.

Response when exceeded:

{
  "success": false,
  "error": "Service temporarily unavailable. Please try again later."
}

HTTP Status: 503 Service Unavailable

Headers:

Retry-After: 60

When a rate limit is exceeded, the offending API key or IP is automatically blocked for 5 minutes.

Error messages never expose:

• Internal system details
• API keys or sensitive data
• File paths or system information
• Stack traces in production

All errors follow a consistent format:

{
  "success": false,
  "error": "Human-readable error message"
}

All production endpoints must use HTTPS.

• API keys transmitted securely
• Prevents man-in-the-middle attacks
• Webhook URLs should also use HTTPS

HTTP is allowed for localhost development only.

• Environment variables only (API_KEYS)
• Never committed to git
• Never logged or exposed in responses
• Rotatable without code changes

Support for multiple API keys:

API_KEYS=sk-prod-key-abc123,sk-backup-key-xyz789,sk-client-key-def456

Benefits:

• Key rotation without downtime
• Different keys for different clients
• Easy revocation of specific keys

To rotate keys:

1. Generate new key
2. Add to API_KEYS environment variable
3. Update clients with new key
4. Remove old key from environment variable

No code deployment required.

node test-security.js

This tests:

• ✓ Authentication requirement (no unauthenticated access)
• ✓ URL length validation (max 2048 chars)
• ✓ Webhook URL length validation (max 2048 chars)
• ✓ Request body size validation (max 10KB)
• ✓ JSON parsing validation
• ✓ URL format validation
• ✓ Valid authenticated requests work correctly

All tests should PASS:

• Unauthenticated requests → 401 Unauthorized
• Long URLs → 400 Bad Request
• Large payloads → 413 Payload Too Large
• Invalid JSON → 400 Bad Request
• Invalid URLs → 400 Bad Request
• Valid authenticated requests → 200 OK

Attack: Random users trying to use the API without permission

Prevention: Authentication required for all requests

Response: 401 Unauthorized

Attack: Sending massive payloads (e.g., 5MB URL strings)

Prevention:

• URL length limit: 2048 characters
• Request body limit: 10KB

Response: 400 Bad Request or 413 Payload Too Large

Attack: Trying thousands of requests to discover valid data

Prevention:

• Rate limiting: 100 requests/hour per API key
• Auto-blocking after limit exceeded

Response: 429 Too Many Requests

Attack: Many users/IPs attacking simultaneously

Prevention:

• Global rate limit: 50 requests/minute
• Auto-blocking for 5 minutes

Response: 503 Service Unavailable

Attack: Sending invalid JSON, malformed URLs, etc.

Prevention:

• Strict JSON parsing
• Zod schema validation
• URL format validation

Response: 400 Bad Request

Attack: Exposing API keys in error messages or logs

Prevention:

• Never log API keys
• Sanitized error messages
• Environment variable storage only

Response: Keys remain secure

All responses include appropriate security headers:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1705318200

When rate limited:

Retry-After: 3600

1. Strong API Keys: Use cryptographically random keys
2. Key Rotation: Rotate keys periodically
3. Monitor Usage: Track rate limit hits and failures
4. HTTPS Only: Never use HTTP in production
5. Environment Variables: Never commit keys to git

1. Secure Storage: Store API keys securely (env vars, secrets manager)
2. Rate Limit Headers: Monitor remaining requests
3. Error Handling: Implement retry logic with exponential backoff
4. HTTPS: Always use HTTPS endpoints
5. Validate Input: Validate URLs before sending

Before deploying to production:

• API_KEYS environment variable is set
• API keys are strong and random (min 20 chars)
• API keys are not in git repository
• HTTPS is enforced
• Rate limits are configured appropriately
• Error messages don't expose sensitive data
• Logging doesn't include API keys
• Security tests pass (node test-security.js)
• Health check endpoint is accessible
• Webhook URLs are validated

If an API key is compromised:

1. Immediately remove the key from API_KEYS
2. Generate a new key
3. Update affected clients
4. Review logs for suspicious activity
5. Monitor for abuse

If under attack:

1. Check global rate limit logs
2. Verify legitimate traffic is working
3. Consider temporarily lowering RATE_LIMIT_GLOBAL
4. Railway will auto-scale if needed
5. Contact Railway support if sustained

Monitor for:

• Repeated 429 responses (rate limit abuse)
• Repeated 401 responses (unauthorized attempts)
• Unusual traffic patterns
• Unexpected cost increases

• No personal data is collected
• URLs are logged (consider privacy implications)
• Webhook URLs are logged (may contain sensitive paths)

• Inform users that URLs are processed
• Implement data retention policies
• Consider GDPR compliance if needed
• Document data handling in privacy policy

This document reflects security measures as of v1.0.0.

For updates:

• Check git commits for security-related changes
• Review CHANGELOG.md for security fixes
• Subscribe to dependency vulnerability alerts

If you discover a security vulnerability:

1. Do not create a public GitHub issue
2. Email: [your-security-email]
3. Include: detailed description, steps to reproduce
4. Allow reasonable time for fix before disclosure

• API Documentation
• Railway Deployment Guide
• Rate Limiter Implementation
• Authentication Implementation