jbvc/api-security-best-practices
Implement secure API design patterns including authentication, authorization, input validation, rate limiting, and protection against common API vulnerabilities
55
55%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
42%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description lists concrete security-related capabilities for API design, which is a strength in specificity. However, it completely lacks a 'Use when...' clause, making it difficult for Claude to know when to select this skill over others. The trigger terms are relevant but could be expanded with more natural user language and common technology names.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about securing APIs, implementing authentication/authorization, protecting endpoints, or hardening API security.'
Include common natural trigger terms and technology names users would mention, such as 'OAuth', 'JWT', 'API keys', 'CORS', 'SQL injection', 'XSS', 'OWASP', or 'API security'.
Clarify the scope to distinguish from general web security or application security skills, e.g., specifying REST API or GraphQL API contexts.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: authentication, authorization, input validation, rate limiting, and protection against common API vulnerabilities. These are distinct, identifiable security concerns. | 3 / 3 |
Completeness | Describes what the skill does (implement secure API design patterns) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when...' clause caps completeness at 2, and since the 'when' is entirely absent, this scores at 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'authentication', 'authorization', 'rate limiting', 'input validation', and 'API vulnerabilities' which users might mention, but misses common variations like 'OAuth', 'JWT', 'API keys', 'CORS', 'SQL injection', 'XSS', or 'API security'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on 'secure API design patterns' is somewhat specific, but terms like 'authentication', 'authorization', and 'input validation' could overlap with general security skills, web development skills, or broader API design skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides genuinely useful, executable code examples for API security patterns, which is its primary strength. However, it is severely bloated - much of the content (OWASP explanations, basic security concepts, extensive checklists) is knowledge Claude already has. The monolithic structure with 500+ lines of inline content defeats the purpose of a skill file that should be a concise, actionable reference.
Suggestions
Reduce content by 60-70%: remove explanations of concepts Claude knows (what SQL injection is, why HTTPS matters, OWASP Top 10 descriptions) and keep only the concrete code patterns and project-specific conventions.
Split into multiple files: move JWT auth example to AUTH_PATTERNS.md, input validation to VALIDATION_PATTERNS.md, rate limiting to RATE_LIMITING.md, and reference them from a concise overview.
Remove the 'When to Use This Skill' section entirely and trim the do/don't lists to only non-obvious items that Claude wouldn't already know.
Add explicit validation checkpoints to the workflow: e.g., 'After implementing auth middleware, test with: curl -H "Authorization: Bearer invalid" to verify rejection.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at 500+ lines. Explains concepts Claude already knows (what SQL injection is, why rate limiting matters, what HTTPS is). The OWASP Top 10 list, 'Why Rate Limiting?' bullet points, and extensive do/don't lists are all knowledge Claude possesses. The 'When to Use This Skill' section with 8 bullet points is unnecessary padding. | 1 / 3 |
Actionability | The code examples are fully executable, complete with imports, error handling, and realistic patterns. JWT authentication, input validation with Zod, rate limiting with Redis, and the common pitfalls section all provide copy-paste ready code with both bad and good patterns clearly contrasted. | 3 / 3 |
Workflow Clarity | Steps 1-5 in the overview are listed but are high-level descriptions rather than a clear workflow with validation checkpoints. There's no explicit 'validate your security implementation' feedback loop - the testing step (Step 5) just lists things to test without concrete commands or verification steps. The individual code examples have good internal flow but the overall process lacks validation gates. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with everything inline. The three massive example blocks, best practices, common pitfalls, security checklist, and OWASP list could all be split into separate referenced files. The 'Related Skills' and 'Additional Resources' sections at the end suggest awareness of linking but the core content is not appropriately split. | 1 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (908 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents