# Security Auditor

> Performs comprehensive security audits of KrakenD configurations to identify vulnerabilities, authentication gaps, and security best practices violations with Flexible Configuration support

- Skill: `majiayu000/security-auditor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/security-auditor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/security-auditor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/security-auditor

---


# KrakenD Security Auditor

## Purpose
Performs comprehensive security audits of KrakenD configurations using the native `krakend audit` command with intelligent fallback and automatic Flexible Configuration support. Identifies authentication gaps, authorization issues, exposure risks, and security best practices violations with actionable remediation steps.

## When to activate
- User asks to audit security: "check security", "security audit", "is this secure"
- User mentions security concerns: "secure my api", "security issues", "vulnerabilities"
- User wants to review authentication/authorization: "check auth", "review authentication"
- User wants to find security problems: "security scan", "find security issues"
- After completing configuration changes to verify security posture
- Before production deployment (proactively suggest)

## What this skill does

1. **Performs comprehensive security audit** using smart three-tier approach:
   - Native `krakend audit` command (most comprehensive)
   - Docker-based audit (fallback)
   - Basic security checks (last resort: CORS, auth, rate limiting, debug endpoints)

2. **Auto-detects Flexible Configuration** (CE and EE variants) and adjusts audit accordingly

3. **Categorizes issues** by severity: Critical → High → Medium → Low → Info

4. **Provides specific remediation** with:
   - Exact location (JSON path)
   - Step-by-step fix instructions
   - Example configuration snippets
   - Links to relevant documentation

5. **Checks common vulnerabilities**:
   - Missing or weak authentication/authorization
   - Exposed sensitive endpoints
   - Missing rate limiting (DoS protection)
   - Lack of CORS configuration
   - Debug endpoints in production
   - Insecure headers
   - Overly permissive configurations

## Security Categories

Understanding these helps interpret audit results:

- **authentication**: Missing or weak authentication mechanisms
- **authorization**: Authorization bypasses or inadequate access controls
- **exposure**: Exposed sensitive information or debug endpoints
- **dos-protection**: Lack of rate limiting or abuse prevention
- **security-headers**: Missing security-related HTTP headers
- **encryption**: Weak or missing encryption (TLS, JWT signing)
- **injection**: Potential injection vulnerabilities
- **best-practice**: Security best practice violations

## Tools used
- `audit_security` - Comprehensive security audit (smart 3-tier fallback: native → Docker → basic checks)
- `list_features` - Browse available security features and edition requirements
- `get_feature_config_template` - Get configuration templates for security features
- `search_documentation` - Find relevant security documentation
- `validate_config` - Validate configuration structure alongside security checks

## Security Audit Workflow

### Step 1: Prepare Audit
- Read the configuration file
- Detect Flexible Configuration (CE or EE variant)
- Determine required edition (CE or EE)
- Check for LICENSE file if EE features detected

### Step 2: Run Security Audit
Use `audit_security` tool which automatically:
- Selects best audit method (native → Docker → basic)
- Handles FC detection and configuration
- Infers version from `$schema` field
- Categorizes findings by severity
- Generates remediation guidance

### Step 3: Analyze Results
- Group findings by severity (Critical, High, Medium, Low, Info)
- Identify quick wins vs. long-term improvements
- Highlight authentication/authorization gaps first
- Note edition-specific recommendations

### Step 4: Present Report
- Show severity summary upfront
- Detail critical and high severity issues first
- Provide specific remediation steps
- Include configuration examples
- Link to relevant documentation

### Audit Commands

When showing users how to manually audit, provide command based on: (1) Version from `$schema`, (2) Edition (CE/EE by features), (3) FC detection, (4) LICENSE for EE.

**Examples:**
```bash
# CE audit
docker run --rm -v $(pwd):/etc/krakend krakend:VERSION audit -c /etc/krakend/krakend.json

# EE audit (LICENSE file present)
docker run --rm -v $(pwd):/etc/krakend krakend/krakend-ee:VERSION audit -c /etc/krakend/krakend.json
```

**Accuracy:** Native `krakend audit` (most comprehensive) > Docker > Basic checks (limited scope).
**Images:** `krakend:VERSION` (CE), `krakend/krakend-ee:VERSION` (EE).

## Output format

Provide a clear, actionable security report:

```
# KrakenD Security Audit Report

## Summary
🔍 Audit Method: Native KrakenD (most comprehensive)
⚠️ Issues Found: 3 high, 2 medium, 1 low
🎯 Priority: Address high severity issues immediately

## Critical Issues
None found ✓

## High Severity Issues

### 1. Missing Authentication on Sensitive Endpoints
**Severity**: HIGH
**Category**: authentication
**Location**: $.endpoints[2] (POST /api/users)

**Issue**:
Endpoint accepts POST requests without any authentication mechanism. This allows anonymous users to create resources.

**Remediation**:
1. Add JWT validation to the endpoint:
```json
"extra_config": {
  "auth/validator": {
    "alg": "RS256",
    "audience": ["https://api.example.com"],
    "jwk_url": "https://auth.example.com/.well-known/jwks.json"
  }
}
```

**References**:
- https://www.krakend.io/docs/authorization/jwt-validation/
- https://www.krakend.io/docs/enterprise/authentication/api-keys/

---

### 2. Debug Endpoint Enabled
**Severity**: HIGH
**Category**: exposure
**Location**: $.extra_config["debug_endpoint"]

**Issue**:
Debug endpoint is enabled, exposing internal application state and metrics to potential attackers.

**Remediation**:
Remove or disable the debug endpoint in production:
```json
"extra_config": {
  "debug_endpoint": false
}
```
Or remove the entire "debug_endpoint" configuration block.

**References**:
- https://www.krakend.io/docs/service-settings/debug-endpoint/

## Medium Severity Issues

### 3. Missing CORS Configuration
**Severity**: MEDIUM
**Category**: security-headers
**Location**: $.extra_config (root level)

**Issue**:
No CORS configuration found. This may cause browser requests to fail or allow all origins by default.

**Remediation**:
Add CORS configuration with explicit allowed origins:
```json
"extra_config": {
  "security/cors": {
    "allow_origins": ["https://yourdomain.com"],
    "allow_methods": ["GET", "POST", "PUT"],
    "allow_headers": ["Authorization", "Content-Type"],
    "expose_headers": ["Content-Length"],
    "max_age": "12h",
    "allow_credentials": true
  }
}
```

**References**:
- https://www.krakend.io/docs/service-settings/cors/

## Best Practices Recommendations

✓ Circuit breakers configured for backends
✓ Timeouts configured
⚠️ Consider adding request/response logging for security monitoring
⚠️ Consider implementing API key authentication for service-to-service calls
⚠️ Review and minimize backend exposure (principle of least privilege)

## Next Steps

1. **Immediate**: Fix all high severity issues (authentication, debug endpoint)
2. **Short-term**: Address medium severity issues (CORS, rate limiting)
3. **Long-term**: Implement low severity improvements and best practices
4. **Ongoing**: Run security audits regularly, especially after configuration changes
```

## Best Practices

1. **Severity-first** - Always show critical/high severity issues first (these need immediate action)
2. **Be specific and actionable** - Don't just say "insecure", explain what's wrong and exactly how to fix it
3. **Include context** - Show exact location using JSON paths
4. **Provide examples** - Include working configuration snippets for remediation
5. **Link to docs** - Always include relevant KrakenD documentation URLs
6. **Consider edition** - Recommend CE-compatible solutions unless user has EE
7. **Show audit method** - Indicate which validation method was used (affects comprehensiveness)
8. **Balance security with usability** - Don't recommend overly restrictive configs without explanation
9. **Follow up** - Suggest re-running audit after fixes are applied
10. **Context matters** - Development vs. production requires different security levels

## Examples

### Example 1: User asks "Is my API secure?"

**Response:**
"I'll perform a comprehensive security audit of your KrakenD configuration."

[Use `audit_security`]
[Present structured report as shown above]

"I found 3 high severity issues that should be addressed immediately. Would you like me to help you fix these issues?"

### Example 2: Pre-production security check

**Response:**
"I'll audit your configuration for security issues before production deployment."

[Use `audit_security` with production config]
[Present findings]

"Your configuration has 2 critical issues that must be fixed before production:
1. No authentication on admin endpoints
2. Debug mode still enabled

Would you like me to fix these now?"

### Example 3: Post-fix re-audit

**Response:**
"I'll re-run the security audit to verify your authentication changes."

[Use `audit_security` again]
[Compare with previous results if available]

"Great progress! The authentication issue is now resolved. Remaining items:
- 1 high severity: Debug endpoint still enabled
- 2 medium severity: Missing CORS and rate limiting

Shall we address these next?"

### Example 4: Fallback to basic checks

**Response:**
"KrakenD binary and Docker are not available, so I'll perform basic security checks."

[Use `audit_security` which falls back to basic checks]

"I performed basic security checks and found:
- Missing CORS configuration
- No authentication on POST endpoints
- No rate limiting configured
- Debug endpoint enabled

Note: For a comprehensive audit, install KrakenD or Docker to run the full `krakend audit` command. These basic checks cover common issues but may miss advanced security problems."

## When to Run Security Audits

Proactively suggest security audits:
- ✅ Before initial deployment
- ✅ After any configuration changes
- ✅ After adding new endpoints
- ✅ Before major releases
- ✅ After security incidents
- ✅ Periodically (monthly/quarterly)
- ✅ After upgrading KrakenD versions
- ✅ When changing authentication mechanisms

## Integration & Error Handling

### Integration with other skills
- After `config-builder` creates new config → Suggest security audit
- If `config-validator` finds issues → Mention security-specific audit available
- Before production deployment → Strongly recommend security audit
- If user asks about specific security features → Offer to run full audit

### Error handling
- **Config file not found**: Ask user which file to audit
- **Config is invalid JSON**: Run syntax check first via `config-validator`, then report
- **Audit produces no output**: Explain that no issues were found (best case!)
- **KrakenD audit fails**: Tool automatically falls back to Docker, then basic checks
- **Too many issues (>15)**: Group by severity and offer to show details incrementally
- **Mix of CE/EE features**: Note in recommendations which features require EE