analyzing-api-gateway-access-logs
Parses API Gateway access logs (AWS API Gateway, Kong, Nginx) to detect BOLA/IDOR attacks, rate limit bypass, credential scanning, and injection attempts. Uses pandas for statistical analysis of request patterns and anomaly detection. Use when investigating API abuse or building API-specific threat detection rules.
59
68%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/analyzing-api-gateway-access-logs/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly communicates specific capabilities, includes rich trigger terms from the API security domain, and explicitly states when to use it. It names concrete platforms, attack types, and tools, making it highly distinguishable from other security or log analysis skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: parses API Gateway access logs from named platforms (AWS API Gateway, Kong, Nginx), detects specific attack types (BOLA/IDOR, rate limit bypass, credential scanning, injection attempts), and uses pandas for statistical analysis and anomaly detection. | 3 / 3 |
Completeness | Clearly answers both 'what' (parses API Gateway logs to detect specific attack types using pandas for statistical analysis) and 'when' (explicitly states 'Use when investigating API abuse or building API-specific threat detection rules'). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would say: 'API Gateway', 'access logs', 'BOLA', 'IDOR', 'rate limit bypass', 'credential scanning', 'injection', 'API abuse', 'threat detection', plus specific platform names (AWS API Gateway, Kong, Nginx). These are terms security engineers would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: API Gateway log analysis for specific security threats. The combination of named platforms, specific attack types (BOLA/IDOR), and the API-specific focus makes it very unlikely to conflict with general log analysis or broader security skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a reasonable starting point with some executable Python code for BOLA and credential scanning detection, but falls short on completeness—three of five listed detection patterns lack any concrete implementation. The boilerplate sections waste tokens, and the absence of a coherent investigation workflow or validation steps significantly limits its practical utility for SOC analysts.
Suggestions
Add executable code examples for the remaining detection patterns (rate limit bypass, injection detection, unusual HTTP methods) instead of listing them as bare bullet points.
Define the expected log schema/format (column names, data types) so the pandas code is truly actionable without guesswork.
Add a clear multi-step investigation workflow with sequencing (e.g., 1. Load and validate logs → 2. Run detection queries → 3. Triage results → 4. Escalate confirmed findings) including validation checkpoints.
Remove or drastically shorten the generic 'When to Use' and 'Prerequisites' sections—Claude doesn't need to be told about 'familiarity with security operations concepts.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'When to Use' and 'Prerequisites' sections contain generic boilerplate that doesn't add value (e.g., 'Familiarity with security operations concepts,' 'Access to a test or lab environment'). The core detection content is reasonably lean, but the surrounding fluff wastes tokens. | 2 / 3 |
Actionability | The BOLA detection and 401 surge examples are executable Python snippets, which is good. However, key detection patterns 2, 4, and 5 are listed as bullet points with no code or concrete implementation, making them vague and incomplete. The log format/schema is also unspecified, so the code isn't truly copy-paste ready without assumptions. | 2 / 3 |
Workflow Clarity | There is no clear multi-step workflow or sequencing for an investigation. The skill presents isolated code snippets without a coherent analysis pipeline, no validation steps, no guidance on what to do after detecting anomalies, and no feedback loops for refining detection thresholds or handling false positives. | 1 / 3 |
Progressive Disclosure | The content is organized into sections (When to Use, Prerequisites, Instructions, Examples), which provides basic structure. However, there are no references to supporting files, and the five detection patterns could benefit from being expanded in separate referenced documents rather than being left as unexplained bullet points. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- mukul975/Anthropic-Cybersecurity-Skills
- Commit
0445030
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.