security-patterns
Skill0 starsChanged 5 months agoMITView on GitHub
Application security patterns — authentication, defense-in-depth, input validation, OWASP Top 10, secrets handling, PII masking, and LLM safety. Use when handling auth, untrusted input, or sensitive data.
- Reads credentials
9 other projects use a version of this.
Adopted by
Most recently taken up by
- capture0x/YeepForgetheir own version, first seen Nov 8, 2026
- ku5ic/claude-kittheir own version, first seen Nov 4, 2026
- CrowdStrike/foundry-skillstheir own version, first seen Oct 30, 2026
- edjchapman/claude-code-configtheir own version, first seen Oct 23, 2026
- Eyadkelleh/awesome-claude-skills-securitytheir own version, first seen Oct 8, 2026
- CloudAI-X/claude-workflowtheir own version, first seen Oct 8, 2026
Used with
Projects with it also use security-fuzzing and security-payloads.
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.
EyadkellehSkillsecurity-fuzzing
Essential fuzzing payloads: SQL injection, command injection, special characters. Curated essentials for vulnerability testing.
Also in 3 projects that use this
EyadkellehSkillsecurity-payloads
Essential exploitation payloads: anti-virus test files, file name exploits, malicious files. Curated for testing.
Also in 3 projects that use this
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- CloudAI-X/claude-workflow★ 1.4ksame name
- CloudAI-X/claude-workflow-v2★ 1.4ksame name
- Eyadkelleh/awesome-claude-skills-security★ 388same name
- Eyadkelleh/awesome-skills-security★ 384same name
- CrowdStrike/foundry-skills★ 37same name
- capture0x/YeepForge★ 8same name
- edjchapman/claude-code-config★ 8same name
- ku5ic/claude-kit★ 2same name
- terrene-foundation/pact★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository20 other files it gives its agents.
- context-engineeringSkill
- multi-agent-patternsSkill
- prompt-injection-defenseSkill
- rag-retrievalSkill
- adr-writerSkill
- ci-cdSkill
- playwright-e2eSkill
- structural-searchSkill
- react-server-componentsSkill
- shadcn-uiSkill
- tailwind-v4Skill
- zustand-stateSkill
- accessibilitySkill
- api-designSkill
- database-patternsSkill
- debuggingSkill
- typescript-patternsSkill
- proposal-writerSkill
- task-prioritizationSkill
- sitecore-xmcloudSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 162
Every LLM response MUST pass a 4-stage guardrail pipeline before reaching the user:
- Distinctive: line 295
Create immutable request context
- Distinctive: line 296
Ensure tenant isolation at query level
“Common” is measured: kept by at least 6 in 10 of the 8 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.
Files
Security Patterns
Comprehensive security patterns for building hardened applications. Each category has individual rule files in rules/ loaded on-demand.
Quick Reference
| Category | Rules | Impact | When to Use |
| Authentication | 3 | CRITICAL | JWT tokens, OAuth 2.1/PKCE, RBAC/permissions |
| Defense-in-Depth | 2 | CRITICAL | Multi-layer security, zero-trust architecture |
| Input Validation | 3 | HIGH | Schema validation (Zod/Pydantic), output encoding, file uploads |
| OWASP Top 10 | 2 | CRITICAL | Injection prevention, broken authentication fixes |
| LLM Safety | 3 | HIGH | Prompt injection defense, output guardrails, content filtering |
| PII Masking | 2 | HIGH | PII detection/redaction with Presidio, Langfuse, LLM Guard |
| Scanning | 3 | HIGH | Dependency audit, SAST (Semgrep/Bandit), secret detection |
| Advanced Guardrails | 2 | CRITICAL | NeMo/Guardrails AI validators, red-teaming, OWASP LLM |
Total: 20 rules across 8 categories
Quick Start
# Argon2id password hashing
from argon2 import PasswordHasher
ph = PasswordHasher()
password_hash = ph.hash(password)
ph.verify(password_hash, password)# JWT access token (15-min expiry)
import jwt
from datetime import datetime, timedelta, timezone
payload = {
'sub': user_id, 'type': 'access',
'exp': datetime.now(timezone.utc) + timedelta(minutes=15),
}
token = jwt.encode(payload, SECRET_KEY, algorithm='HS256')// Zod v4 schema validation
import { z } from 'zod';
const UserSchema = z.object({
email: z.email(),
name: z.string().min(2).max(100),
role: z.enum(['user', 'admin']).default('user'),
});
const result = UserSchema.safeParse(req.body);# PII masking with Langfuse
import re
from langfuse import Langfuse
def mask_pii(data, **kwargs):
if isinstance(data, str):
data = re.sub(r'\b[\w.-]+@[\w.-]+\.\w+\b', '[REDACTED_EMAIL]', data)
data = re.sub(r'\b\d{3}-\d{2}-\d{4}\b', '[REDACTED_SSN]', data)
return data
langfuse = Langfuse(mask=mask_pii)Authentication
Secure authentication with OAuth 2.1, Passkeys/WebAuthn, JWT tokens, and role-based access control.
| Rule | Description |
auth-jwt.md | JWT creation, verification, expiry, refresh token rotation |
auth-oauth.md | OAuth 2.1 with PKCE, DPoP, Passkeys/WebAuthn |
auth-rbac.md | Role-based access control, permission decorators, MFA |
Key Decisions: Argon2id > bcrypt | Access tokens 15 min | PKCE required | Passkeys > TOTP > SMS
Defense-in-Depth
Multi-layer security architecture with no single point of failure.
| Rule | Description |
defense-layers.md | 8-layer security architecture (edge to observability) |
defense-zero-trust.md | Immutable request context, tenant isolation, audit logging |
Key Decisions: Immutable dataclass context | Query-level tenant filtering | No IDs in LLM prompts
sandbox.network.deniedDomains (CC 2.1.113+)
Network-layer blocklist enforced before Bash/WebFetch egress — pair with the hook-layer DENY_PATTERNS for defense in depth. Settings example:
"sandbox": {
"network": {
"deniedDomains": ["*.evil.com", "pastebin.com", "transfer.sh"]
}
}Wildcards supported (*.example.com, evil.com/*/malicious/*). Plugins ship a baseline list in src/settings/ork.settings.json; project settings can extend it. Use for: prompt-injection exfil sinks, known-bad registries, paste services that bypass audit.
Input Validation
Validate and sanitize all untrusted input using Zod v4 and Pydantic.
| Rule | Description |
validation-input.md | Schema validation with Zod v4 and Pydantic, type coercion |
validation-output.md | HTML sanitization, output encoding, XSS prevention |
validation-schemas.md | Discriminated unions, file upload validation, URL allowlists |
Key Decisions: Allowlist over blocklist | Server-side always | Validate magic bytes not extensions
OWASP Top 10
Protection against the most critical web application security risks.
| Rule | Description |
owasp-injection.md | SQL/command injection, parameterized queries, SSRF prevention |
owasp-broken-auth.md | JWT algorithm confusion, CSRF protection, timing attacks |
Key Decisions: Parameterized queries only | Hardcode JWT algorithm | SameSite=Strict cookies
LLM Safety
Security patterns for LLM integrations including context separation and output validation.
| Rule | Description |
llm-prompt-injection.md | Context separation, prompt auditing, forbidden patterns |
llm-guardrails.md | Output validation pipeline: schema, grounding, safety, size |
llm-content-filtering.md | Pre-LLM filtering, post-LLM attribution, three-phase pattern |
Key Decisions: IDs flow around LLM, never through | Attribution is deterministic | Audit every prompt
Context Separation (CRITICAL)
Sensitive IDs and data flow AROUND the LLM, never through it. The LLM sees only content — mapping back to entities happens deterministically after.
# CORRECT: IDs bypass the LLM
context = {"user_id": user_id, "tenant_id": tenant_id} # kept server-side
llm_input = f"Summarize this document:\n{doc_text}" # no IDs in prompt
llm_output = call_llm(llm_input)
result = {"summary": llm_output, **context} # IDs reattached afterOutput Validation Pipeline
Every LLM response MUST pass a 4-stage guardrail pipeline before reaching the user:
def validate_llm_output(raw_output: str, schema, sources: list[str]) -> str:
# 1. Schema — does it match expected structure?
parsed = schema.parse(raw_output)
# 2. Grounding — are claims supported by source documents?
assert_grounded(parsed, sources)
# 3. Safety — toxicity, PII leakage, prompt leakage
assert_safe(parsed, max_toxicity=0.5)
# 4. Size — prevent token-bomb responses
assert len(parsed.text) < MAX_OUTPUT_CHARS
return parsed.textPII Masking
PII detection and masking for LLM observability pipelines and logging.
| Rule | Description |
pii-detection.md | Microsoft Presidio, regex patterns, LLM Guard Anonymize |
pii-redaction.md | Langfuse mask callback, structlog/loguru processors, Vault deanonymization |
Key Decisions: Presidio for enterprise | Replace with type tokens | Use mask callback at init
Scanning
Automated security scanning for dependencies, code, and secrets.
| Rule | Description |
scanning-dependency.md | npm audit, pip-audit, Trivy container scanning, CI gating |
scanning-sast.md | Semgrep and Bandit static analysis, custom rules, pre-commit |
scanning-secrets.md | Gitleaks, TruffleHog, detect-secrets with baseline management |
Key Decisions: Pre-commit hooks for shift-left | Block on critical/high | Gitleaks + detect-secrets baseline
Advanced Guardrails
Production LLM safety with NeMo Guardrails, Guardrails AI validators, and DeepTeam red-teaming.
| Rule | Description |
guardrails-nemo.md | NeMo Guardrails, Colang 2.0 flows, Guardrails AI validators, layered validation |
guardrails-llm-validation.md | DeepTeam red-teaming (40+ vulnerabilities), OWASP LLM Top 10 compliance |
Key Decisions: NeMo for flows, Guardrails AI for validators | Toxicity 0.5 threshold | Red-team pre-release + quarterly
Managed Hook Hierarchy (CC 2.1.49)
Plugin settings follow a 3-tier precedence:
| Tier | Source | Overridable? |
1. Managed (plugin settings.json) | Plugin author ships defaults | Yes, by user |
2. Project (.claude/settings.json) | Repository config | Yes, by user |
3. User (~/.claude/settings.json) | Personal preferences | Final authority |
Security hooks shipped by the project are managed defaults — users can disable them but are warned. Enterprise admins can lock settings via managed profiles.
CC 2.1.166 — managed-settings enforcement fix: before 2.1.166 a single invalid entry in managed settings silently disabled enforcement of all remaining valid policies — one typo could void your entire security lockdown. Require 2.1.166+ when relying on managed profiles, and validate the file before deploying it. The same release fixed
allowedMcpServers/deniedMcpServerspredicates not matching when they use${VAR}references.
CC 2.1.160 — write prompts: Claude Code now prompts before writing shell startup files (
.zshenv,.zlogin,.bash_login,~/.config/git/) and — underacceptEdits— build-tool configs that grant code execution (.npmrc,.yarnrc*,bunfig.toml,.bazelrc,.pre-commit-config.yaml,.devcontainer/). Treat these as defense-in-depth defaults: approve deliberately rather than blanket-allowing.
Permission-rule semantics (≥ 2.1.166):
allow/ask/denyrules gained security-relevant behavior —Readdeny now hides files from Glob/Grep, deny tool-names accept globs ("*"= default-deny), explicitWebFetch(domain:…)overrides the preapproved-host auto-allow, relayedSendMessagefrom other sessions carries no authority, and org-managed rules apply for the whole session. Seereferences/cc-permission-model.mdfor the full model + a recommended baselinesettings.json.
Anti-Patterns (FORBIDDEN)
# Authentication
user.password = request.form['password'] # Plaintext password storage
response_type=token # Implicit OAuth grant (deprecated)
return "Email not found" # Information disclosure
# Input Validation
"SELECT * FROM users WHERE name = '" + name + "'" # SQL injection
if (file.type === 'image/png') {...} # Trusting Content-Type header
# LLM Safety
prompt = f"Analyze for user {user_id}" # ID in prompt
artifact.user_id = llm_output["user_id"] # Trusting LLM-generated IDs
# PII
logger.info(f"User email: {user.email}") # Raw PII in logs
langfuse.trace(input=raw_prompt) # Unmasked observability dataDetailed Documentation
Load on demand with Read("${CLAUDE_SKILL_DIR}/references/<file>"):
| File | Content |
cc-permission-model.md | CC allow/ask/deny rule semantics (≥2.1.166): Read-deny hides from Glob/Grep, deny-globs, WebFetch precedence, cross-session auth, org-managed rules |
oauth-2.1-passkeys.md | OAuth 2.1, PKCE, DPoP, Passkeys/WebAuthn |
request-context-pattern.md | Immutable request context for identity flow |
tenant-isolation.md | Tenant-scoped repository, vector/full-text search |
audit-logging.md | Sanitized structured logging, compliance |
zod-v4-api.md | Zod v4 types, coercion, transforms, refinements |
vulnerability-demos.md | OWASP vulnerable vs secure code examples |
context-separation.md | LLM context separation architecture |
output-guardrails.md | Output validation pipeline implementation |
pre-llm-filtering.md | Tenant-scoped retrieval, content extraction |
post-llm-attribution.md | Deterministic attribution pattern |
prompt-audit.md | Prompt audit patterns, safe prompt builder |
presidio-integration.md | Microsoft Presidio setup, custom recognizers |
langfuse-mask-callback.md | Langfuse SDK mask implementation |
llm-guard-sanitization.md | LLM Guard Anonymize/Deanonymize with Vault |
logging-redaction.md | structlog/loguru pre-logging redaction |
Related Skills
api-design-framework- API security patternsork:rag-retrieval- RAG pipeline patterns requiring tenant-scoped retrievalllm-evaluation- Output quality assessment including hallucination detection
Capability Details
authentication
Keywords: password, hashing, JWT, token, OAuth, PKCE, passkey, WebAuthn, RBAC, session Solves:
- Implement secure authentication with modern standards
- JWT token management with proper expiry
- OAuth 2.1 with PKCE flow
- Passkeys/WebAuthn registration and login
- Role-based access control
defense-in-depth
Keywords: defense in depth, security layers, multi-layer, request context, tenant isolation Solves:
- How to secure AI applications end-to-end
- Implement 8-layer security architecture
- Create immutable request context
- Ensure tenant isolation at query level
cc-subprocess-hardening (CC 2.1.98)
Keywords: subprocess, sandbox, PID namespace, env scrub, script caps Solves:
- Limit runaway hook scripts:
CLAUDE_CODE_SCRIPT_CAPS=100 - Strip credentials from subprocesses:
CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 - PID namespace isolation on Linux for subprocess sandboxing
- Prevent Bash permission bypasses via backslash escapes and compound commands
CC 2.1.128 — SDK host "Always allow" persistence: when a user picks "Always allow" from a Bash permission prompt in an SDK host, the grant now persists via
.claude/settings.local.jsoninstead of evaporating at session end. Audit your SDK consumers'.gitignoreto confirm.claude/settings.local.jsonis excluded — committing it leaks per-developer Bash auth grants. Project-committed.claude/settings.jsonis unchanged; only the user-machine-local file receives the new entries.
CC 2.1.163 — home-path deny rules now cover
$HOMEBash refs: before this fix aRead(~/.ssh/**)-style deny rule blocked the Read tool but NOT a Bash command that reached the same file via$HOME/.ssh/...— a silent secrets-read bypass. If you gate home-directory secrets (e.g.~/.aws/credentials,~/.ssh/*,~/.gnupg/*) through permission deny rules, pin your CC floor to>= 2.1.163; older builds (< 2.1.163) leave the Bash path open — ork's floor is now2.1.168, which already includes this fix.
input-validation
Keywords: schema, validate, Zod, Pydantic, sanitize, HTML, XSS, file upload Solves:
- Validate input against schemas (Zod v4, Pydantic)
- Prevent injection attacks with allowlists
- Sanitize HTML and prevent XSS
- Validate file uploads by magic bytes
owasp-top-10
Keywords: OWASP, sql injection, broken access control, CSRF, XSS, SSRF Solves:
- Fix OWASP Top 10 vulnerabilities
- Prevent SQL and command injection
- Implement CSRF protection
- Fix broken authentication
llm-safety
Keywords: prompt injection, context separation, guardrails, hallucination, LLM output Solves:
- Prevent prompt injection attacks
- Implement context separation (IDs around LLM)
- Validate LLM output with guardrail pipeline
- Deterministic post-LLM attribution
pii-masking
Keywords: PII, masking, Presidio, Langfuse, redact, GDPR, privacy Solves:
- Detect and mask PII in LLM pipelines
- Integrate masking with Langfuse observability
- Implement pre-logging redaction
- GDPR-compliant data handling
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
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.

