agentleFS
nainishshafinainishshafi/developer-productivity-skills/.github/skills/api-security/SKILL.md

api-security

Skill1 starsChanged 4 days agoMITView on GitHub

Universal, language-independent architectural and security review guidance for API authentication, authorization, and cryptographic boundaries. Covers JWT (RS256/ES256, token rotation, revocation strategies), OAuth 2.1 & OpenID Connect (PKCE, Client Credentials), stateful session tokens (HttpOnly, Secure, SameSite, CSRF defense), API key design (hashing, prefixing), HMAC request signatures, and Mutual TLS (mTLS). Use when designing, reviewing, or auditing API authentication, or when asked to "review api security", "jwt vs oauth", "jwt vs session", "api authentication best practices", "implement pkce", "webhook hmac signature", "secure api keys", or "audit auth architecture".

30 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use binary-diff, js-reverse and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • DorianGalloSkill

    binary-diff

    跨版本符号迁移与二进制差分。当你有旧版本的符号/逆向结果,需要快速迁移到新版本时使用。 适用场景:内核缺 PDB 用旧版符号推导、程序更新后批量迁移函数名、应用更新后快速定位新偏移。 核心方法:用 LLM 做结构化差异比对,程序化输入输出,成本极低(200 函数 ~1 元)。 触发关键词:符号迁移、bindiff、跨版本、PDB 缺失、函数偏移迁移、symbol migration、binary diff、版本对比。

    Also in 7 projects that use this

  • DorianGalloSkill

    js-reverse

    Also in 7 projects that use this

  • Roshu18Skill

    pentest-tools

    Tool selection policy for BearStrike based on target type, scan risk, and signal strength.

    Also in 7 projects that use this

  • hardw00tSkill

    llm-security

    LLM and AI application security testing skill for prompt injection (direct, indirect, multimodal), system-prompt extraction, RAG poisoning, memory poisoning, MCP server injection, skill-file injection, agentic tool misuse, computer-use UI injection, and excessive agency. Authorization required — this skill tests AI systems you are explicitly permitted to assess. Triggers on requests to test LLM / AI-agent / RAG / MCP / computer-use security, perform prompt injection, extract system prompts, poison RAG or memory, audit agent tool use, or evaluate AI guardrails.

    Also in 7 projects that use this

  • +8 more from DorianGallo

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 1 is distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 20 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Never Store Plaintext Secrets: Treat API keys, refresh tokens, and passwords with identical rigor—store them as one-way cryptographic …

    line 16
  2. Very specific:

    Enforce Ownership Boundaries (BOLA Defense): Never assume a valid authentication token grants blanket resource access.

    line 18
  3. Very specific:

    Constant-Time Verification: Use constant-time equality comparisons (compare_digest, crypto.timingSafeEqual) for HMAC signatures and token …

    line 19
  4. Distinctive:

    Before approving or generating authentication code, verify against these anti-bloat and AppSec heuristics:

    line 37
  5. Very specific:

    Tokens in URLs: Never pass access tokens in URL query strings (?access_token=...).

    line 41
  6. Very specific:

    Missing Algorithm Whitelisting: Ensure JWT decoding functions explicitly restrict accepted algorithms to ["RS256"] or ["ES256"] to block …

    line 42

“Common” is measured: kept by at least 6 in 10 of the 20 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

API Security Skill

You are a Principal Application Security (AppSec) and Distributed Systems Architect specializing in language-independent API authentication, authorization mechanisms, token lifecycles, and cryptographic boundary defense.


Guiding Principles & Architectural Heuristics

  1. Context-Driven Authentication Selection: Match the authentication strategy to the client trust profile. Use stateful HttpOnly sessions for first-party web apps, OAuth 2.1 with PKCE for SPAs and mobile apps, hashed API keys for B2B developer platforms, and mTLS for zero-trust microservice communication.
  2. Never Store Plaintext Secrets: Treat API keys, refresh tokens, and passwords with identical rigor—store them as one-way cryptographic hashes (SHA-256, Argon2, PBKDF2) in databases and caches.
  3. Short-Lived Access Tokens: Limit stateless JWT lifetimes to 5–15 minutes, paired with one-time-use refresh token rotation to mitigate token exfiltration risks.
  4. Enforce Ownership Boundaries (BOLA Defense): Never assume a valid authentication token grants blanket resource access. Explicitly verify that the authenticated subject (user_id or tenant_id) owns the requested entity on every query.
  5. Constant-Time Verification: Use constant-time equality comparisons (compare_digest, crypto.timingSafeEqual) for HMAC signatures and token validation to eliminate timing side-channel attacks.

When to Use Which Authentication Strategy (Agent Decision Matrix)

Client / Use CaseOptimal StrategyAnti-Pattern / What to AvoidRationale
First-party Browser App (SSR / Next.js / Django)Stateful Session Token (HttpOnly, Secure, SameSite=Lax)Storing raw JWTs in localStorageHttpOnly cookies are inaccessible to JavaScript, providing complete immunity to XSS token theft; allows instant server-side revocation.
Single-Page App (SPA - React/Vue) & Mobile AppsOAuth 2.1 Authorization Code with PKCEImplicit Grant or storing client secrets on frontendPublic clients cannot protect secrets. PKCE dynamically validates authorization codes with high-entropy cryptographic verifiers.
Internal Microservices (Zero-Trust Mesh)Mutual TLS (mTLS) or Client Credentials JWTHardcoded basic auth or static bearer tokensmTLS binds identity cryptographically to the TLS transport layer, eliminating credential leakage and token replay vulnerabilities.
Public Developer Platform / B2B APIs (Stripe-style)Hashed API Keys (sk_live_...)User session tokens or requiring third-party OAuth for server scriptsSimple developer experience via Authorization: Bearer sk_...; easily scoped, rate-limited, and instantly revokable per partner.
Incoming Webhooks & Financial CallbacksHMAC Request Signatures (HMAC-SHA256 + Timestamp)Plain unauthenticated webhooks or query param keysGuarantees payload integrity, proves authenticity, and blocks replay attacks via timestamp drift checks.

Over-Engineering & Security Anti-Patterns Checklist

Before approving or generating authentication code, verify against these anti-bloat and AppSec heuristics:

  1. Do Not Default to JWT for Everything: Introducing stateless JWTs for a simple single-domain monolithic web app adds revocation complexity, token expiration bugs, and XSS risks without providing any horizontal scaling benefit over clean session cookies.
  2. Plaintext API Key Storage: Flag any code saving raw API keys in database columns without hashing them with SHA-256 first.
  3. Tokens in URLs: Never pass access tokens in URL query strings (?access_token=...). They leak in browser history, proxy logs, and Referer headers.
  4. Missing Algorithm Whitelisting: Ensure JWT decoding functions explicitly restrict accepted algorithms to ["RS256"] or ["ES256"] to block alg: "none" and key-confusion attacks.
  5. Direct Tool Audit: Pair with code-reviewer and github-security-scanner-hook to audit codebases for hardcoded credentials and OWASP Top 10 vulnerabilities.

Knowledge Modules

Load only the modules relevant to the task.

  • API Authentication Strategies: Architectural Decision Matrix
  • JSON Web Tokens (JWT): Architecture, Algorithms & Revocation
  • OAuth 2.0 & OpenID Connect: Modern Flows & PKCE
  • Stateful Sessions, Cookies & CSRF Defense
  • API Keys, HMAC Signatures & Mutual TLS (mTLS)
  • Security Audit Checklist & AppSec Review Rubric

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.