---

name: software-security-appsec description: "Reviews application security and guides AppSec design. Use when reviewing auth, authentication, authorization, sessions, data handling, supply chain, or AppSec architecture." compatibility: Portable core. Works on Claude Code and Codex. version: "1.3" last_validated: 2026-07-11

Software Security And AppSec

Use this skill for application-layer security: authentication, authorization, input and output handling, cryptography, supply-chain controls, API security, threat modeling, and security reviews. It is the AppSec decision layer, not general backend or infrastructure hardening.

Quick Reference

Task	Use
Risk-category framing	references/owasp-top-10.md
Auth and authorization choices	references/authentication-authorization.md, assets/web-application/template-authentication.md, assets/web-application/template-authorization.md
Input handling, uploads, rendering, and common bugs	references/input-validation.md, references/common-vulnerabilities.md
Secure design and threat modeling	references/secure-design-principles.md, references/threat-modeling-guide.md
API and supply-chain security	references/api-security-patterns.md, references/supply-chain-security.md, assets/api/template-secure-api.md
Crypto, password hashing, and transport choices	references/cryptography-standards.md
Agentic, LLM, and MCP application design	references/agentic-llm-appsec.md (testing lives in qa-security-testing)
Mobile secure storage, pinning policy, attestation	assets/mobile/template-mobile-security.md
Secret-storage selection	See "Secret-Storage Selection" below — choosing encrypted vs plaintext at the provider, and how to verify after storing
Incident response and security program framing	references/incident-response-playbook.md, references/security-business-value.md, references/operational-playbook.md

Secret-Storage Selection

Choose the provider's credential storage and verify who can read values; encryption at rest does not imply write-only access or complete read auditing.

Provider	Credential storage	Check before use
Cloudflare Workers	wrangler secret put	Secret binding rather than a plain vars binding; see Workers secrets
Vercel	Secret environment variable	Confirm the current write-only option and environment scope in Vercel docs; a readable Config value may still be encrypted
GitHub Actions	Repository / Organization Secrets	Restrict workflow and environment access; keep credentials out of workflow env: literals and repository Variables
AWS	Secrets Manager or SSM SecureString	Restrict decrypt/read permissions; authorized clients can retrieve plaintext (Secrets Manager retrieval)
Kubernetes	Secret with configured encryption at rest	Base64 alone is not encryption; restrict API and Pod-creation access (Kubernetes Secrets)

Use secret storage for API keys, signing keys, passwords and webhook secrets. Public identifiers belong in ordinary configuration. For multiline values, prefer a protected file or provider CLI input and verify exact bytes through an authorized test without printing the value; do not assume every dashboard corrupts newlines.

If a credential was exposed to unauthorized readers, revoke and rotate it at the issuer, remove exposed copies, and verify the replacement's scope. Storage in readable configuration warrants an exposure assessment; it does not by itself prove compromise.

When to Use

• Review or design auth, session, token, or authorization flows.
• Validate input handling, uploads, rendering, and untrusted-data boundaries.
• Secure APIs, webhooks, browser apps, and admin surfaces.
• Threat-model a feature or AppSec architecture choice.
• Harden dependency, build, artifact, and release paths.
• Review agentic or MCP-connected applications from an AppSec angle.

Route Elsewhere

• General backend engineering without a security focus: use software-backend.
• Infrastructure hardening, IAM, cluster policy, or cloud posture: use ops-devops-platform.
• Smart-contract-specific audits: use software-crypto-web3 (owns the audit methodology in references/smart-contract-security-auditing.md).
• Security test tooling and coverage (SAST/DAST, LLM/agentic test suites): use qa-security-testing.
• ML pipeline or model-ops governance: use ai-mlops.
• Compliance-only interpretation with no implementation choice: route to legal or compliance stakeholders.
• Reverse engineering of shipped binaries, APK/IPA, Electron/ASAR, firmware, or decompilation: this library does not own it. Use the upstream REA skill and MCP server from morluto/rea (MIT) rather than a copy here, because it is tied to REA's tool names and versions. It executes analysis on local binaries, so review it as a third-party skill (agents-skills, "Review a third-party skill before installing") and pin a version before installing.

Defaults

• Use OWASP Top 10 for risk framing, ASVS for requirements depth, and NIST SSDF for SDLC baselines. At selection time, read the publishers' pages, record the edition and status applied, and distinguish a draft from a final standard: OWASP Top 10, ASVS, SSDF, SLSA, NIST digital identity, WebAuthn, OWASP GenAI. CRA applicability is covered in supply-chain-security.md.
• Prefer passkeys where feasible and sessions for browser-first apps.
• Model trust boundaries before choosing controls.
• Treat tool calls, retrieved content, and long-term memory as untrusted input in agentic systems.

Workflow

1. Identify the asset, trust boundary, attacker capability, and failure consequence.
2. Classify the problem: auth, authZ, untrusted input, API, supply chain, agentic flow, or secure-design issue.
3. Choose the control family from the relevant reference.
4. Apply the concrete safeguards and define verification depth.
5. Recheck volatile standards and provider behavior before final recommendations.

Scoping a self-audit with an AI reviewer: state that the team owns the code and the goal is remediation; review one module or trust boundary per pass; run static tools (SAST, dependency audit, secret scan) first and have the reviewer triage their output against the real code path; ask for fixes and safe reproductions, not exploit payloads. A whole-repository "find all vulnerabilities" prompt gives shallow, unverifiable findings and can trip provider safety filters.

Auth Model Selection

Situation	Choose	Avoid
Product with browser users, session state acceptable	Server sessions (cookie + server-side store)	JWTs for sessions — revocation is hard
Mobile/desktop app with device-native biometrics	Passkeys (WebAuthn)	SMS OTP — SIM-swap risk
Third-party sign-in or delegated access	OIDC for identity; OAuth authorization-code flow + PKCE for delegated access	Implicit flow; apply RFC 9700 security guidance
API-to-API, no user context	mTLS or short-lived signed tokens	Long-lived API keys
Intra-service auth in a trusted cluster	Service accounts + mTLS	Shared secrets or user tokens

Input Control Selection

Sink / operation	Required control
SQL query construction	Parameterized query or ORM binding; never string concatenation
Shell / process execution	Allowlist args; avoid shell=True / exec with user input
HTML rendering	Context-aware output encoding; CSP header
File upload destination path	Canonicalize; reject path traversal sequences; store outside webroot
Redirect target	Allowlist known origins; reject open redirect patterns
LDAP / XPath / XML	Library-level escaping or schema validation before query construction
LLM / agent tool call input	Treat as untrusted; validate schema before execution; log intent + scope

Core Decisions

Authentication and Sessions

Default choices:

• passkeys when product and recovery flows support them
• server sessions for browser apps
• OIDC for sign-in; OAuth authorization-code flow plus PKCE for delegated access, following RFC 9700. Check OAuth 2.1 status before presenting it as a final standard
• short-lived tokens only when true statelessness is required

Choose the simplest safe model that matches the app shape.

Authorization and Input Boundaries

Minimum rules:

• deny by default
• check authorization on the server
• validate at boundaries
• parameterize dangerous sinks
• treat rich content and file uploads as active content until proven otherwise

Secure Design and Threat Modeling

Threat-model before implementing:

• storage of sensitive data
• privileged actions
• external callbacks
• file uploads
• rich rendering
• agent or tool flows

Retroactive hardening is slower and weaker than secure-by-default design.

Agentic and MCP Security

Model explicitly:

• prompt injection
• tool misuse
• memory poisoning
• cross-tenant leakage
• over-broad server capabilities
• unsafe approval flows

Keep read-only and mutating capabilities separate and log intent, scope, and result. Never let one context combine untrusted content, private data, and an exfiltration or mutation channel. Threat-to-control design: references/agentic-llm-appsec.md.

Metered or costly actions (single-source design pattern): for any agent action that consumes a bounded quota, spends money, or is otherwise costly/irreversible, re-check current authorization and quota state immediately before that specific call, not from an earlier cached check. Apply the user-authorized budget and action scope; request fresh confirmation when a call would exceed them or when the authorization requires confirmation per call. On failure mid-run, resume from saved state rather than restarting, since restarting re-incurs the metered cost.

Supply-Chain and Release Integrity

Use:

• lockfiles
• trusted publishing or provenance
• artifact integrity checks
• SBOM where relevant
• explicit review of transitive risk

Verification Checklist

Finding evidence gate.

For each security finding, identify the attacker capability, reachable entry point, trust-boundary crossing, sink, and concrete impact. Separate confirmed exploit paths from defense-in-depth gaps and unverified hypotheses. Supply a safe reproduction or code-path trace plus the smallest viable remediation; severity follows exploitability and impact, not the presence of a risky-looking API alone.

Before finalizing any AppSec design or review output:

• Trust boundary drawn explicitly — every input crossing it is validated or rejected
• Authentication model chosen from Defaults (passkeys → server session → OIDC/PKCE → short-lived token)
• Authorization checked server-side; deny-by-default enforced at every privileged endpoint
• All sinks parameterized: SQL, shell, LDAP, XPath, XML, HTML rendering, redirect targets
• File uploads and rich content treated as active content: type validation, size limit, storage isolation
• Credentials use provider secret storage; verify read permissions, environment scope and encryption configuration
• Supply-chain controls in place: lockfile, dependency scanning, artifact integrity, SBOM if required
• Agentic flows threat-modeled for prompt injection, tool misuse, cross-tenant leakage, and over-broad scopes
• Residual risks documented with mitigating controls and owner
• Standards and browser-behavior claims verified against current sources before final output

Output Modes

Default to one of these:

• Security design brief: threats, control choices, and verification scope.
• Security review: findings, risks, and implementation priorities.
• Auth or API hardening plan: recommended model, pitfalls, and validation steps.
• Agentic AppSec review: threat model, capability boundaries, and approval controls.

Known Traps

• Starting security review after architecture and product flows are already fixed, which turns foundational design issues into expensive compensating controls.
• Conflating authentication with authorization and assuming a valid identity token answers the permission question.
• Treating file uploads, rich text, markdown, or retrieved tool content as passive data instead of active attacker-controlled input.
• Reusing one permission surface for both read-only and mutating tool or MCP actions.
• Assuming infrastructure posture or a managed platform compensates for weak application-level control design.
• Shipping a CSP with 'unsafe-inline' or 'unsafe-eval' as the default. Each one removes much of the XSS protection the policy exists for; treat any that a dependency forces as debt with an owner and a plan to move to nonces or hashes.

Anti-Patterns

• Treating standards status as evergreen without checking.
• Using auth mechanisms that are more complex than the app needs.
• Trusting unvalidated input deep in the system.
• Leaving tool or MCP permissions broad by default.
• Bolting security onto a feature after implementation choices are locked.
• Conflating infrastructure posture with application security design.

Navigation

• For control prioritization under uncertain attacker incentives, load game-theory-applied.md; for availability tradeoffs, load reliability-theory-applied.md.
• For lateral trust boundaries, load zero-trust-architecture.md.
• For advanced browser payloads or .NET crypto integration, load advanced-xss-techniques.md or dotnet-efcore-crypto-security.md.
• For contract-code risks, follow the software-crypto-web3 handoff above and use assets/web3/crypto-security.md for the vulnerability catalogue.
• When a claim needs source lookup, consult data/sources.json.

Attribution: the metered/costly-action authorization-check pattern under Agentic and MCP Security is adapted from regulatory-threat-model by Ansvar Systems AB, in davila7/claude-code-templates at commit 22d8efa9e9afcf31b98b7e3952ec557694e72c13, licensed CC-BY-4.0. Extracted 2026-08-09. This is a single-source pattern (medium confidence) extracted from one vendor-specific, proprietary-tool-bound skill — treat it as a named pattern to consider, not a widely-corroborated convention.

Learnings Loop

When prior decisions or pitfalls are relevant, consult learnings.consolidated.md if present; use learnings.md only for needed history or as the available fallback. Otherwise skip both.

After applying it, if you encountered a pattern worth remembering, a mistake worth preventing, or a domain fact that surprised you, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.