input-validation

Use when implementing input validation and output encoding to prevent injection attacks. Covers validation strategies, context-specific output encoding, parameterized queries, and defense-in-depth approaches across all languages and frameworks. USE FOR: input validation, output encoding, XSS prevention, SQL injection prevention, command injection prevention, parameterized queries, sanitization, allowlisting, content security policy DO NOT USE FOR: authentication validation (use authentication), API rate limiting (use api-security), cryptographic validation (use cryptography)

Ir para a instalação

Repositório: Tyler-R-Kendrick/agent-skills
Última atividade na origem: 11 de fevereiro de 2026 às 05:14
Idioma detectado do SKILL.md: inglês
Estrelas: 10
Forks: 4

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Voltar à pesquisa Voltar à instalação

name	input-validation
description	Use when implementing input validation and output encoding to prevent injection attacks. Covers validation strategies, context-specific output encoding, parameterized queries, and defense-in-depth approaches across all languages and frameworks. USE FOR: input validation, output encoding, XSS prevention, SQL injection prevention, command injection prevention, parameterized queries, sanitization, allowlisting, content security policy DO NOT USE FOR: authentication validation (use authentication), API rate limiting (use api-security), cryptographic validation (use cryptography)
license	MIT
metadata	{"displayName":"Input Validation & Output Encoding","author":"Tyler-R-Kendrick"}
compatibility	claude, copilot, cursor
references	[{"title":"OWASP Input Validation Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html"},{"title":"OWASP Cross-Site Scripting Prevention Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html"},{"title":"OWASP SQL Injection Prevention Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"}]

Input Validation & Output Encoding

Overview

Input validation and output encoding form a defense-in-depth strategy against injection attacks. Neither is sufficient on its own:

Input validation ensures that data conforms to expected formats before processing. It reduces the attack surface but cannot account for every output context.
Output encoding ensures that data is rendered safely in its target context (HTML, SQL, JavaScript, etc.). It neutralizes malicious content but should not be the only line of defense.

Always apply both: validate all input as early as possible, and encode all output as late as possible — immediately before it is rendered or interpreted in its target context.

Input Validation Strategy

Allowlist vs. Denylist

Always prefer allowlist (positive) validation. Define what is permitted and reject everything else. Allowlists are explicit, predictable, and far harder to bypass.
Denylist (negative) validation is fragile. Blocking known-bad patterns always misses novel attack vectors, encoding tricks, and edge cases.

Principles

Validate as early as possible — at the API boundary, form handler, or deserialization layer before data enters business logic.
Normalize before validating — decode, trim, and canonicalize input before applying validation rules. Attackers exploit double-encoding and Unicode normalization differences to bypass checks.
Use typed validation — parse inputs into their expected types (integers, dates, enums) rather than treating everything as strings. Type coercion eliminates entire classes of injection.
Validate on the server side — client-side validation improves UX but provides zero security. All validation must be enforced server-side.

Validation by Data Type

Data Type	Validation Rule	Example
Strings	Max length, allowed character set, regex pattern	Username: `^[a-zA-Z0-9_]{3,30}$`
Numbers	Type check, min/max range, integer vs. float	Age: integer, 0-150
Emails	RFC 5322 format validation + DNS MX record check	`user@example.com` — verify domain has MX records
URLs	Scheme allowlist (https only), reject internal/private IPs

Context	Encoding Method	Example
HTML body	HTML entity encode	`<script>` becomes `<script>`
HTML attributes	HTML attribute encode	`" onclick="alert(1)` becomes `" onclick="alert(1)`
JavaScript	JavaScript encode / `JSON.stringify()`	Embed user data only via `JSON.stringify()` into a variable assignment
URL parameters	URL encode (percent-encoding)	`param=hello world` becomes `param=hello%20world`
CSS	CSS hex encode	`</style>` becomes `\003c\002fstyle\003e`
SQL	Parameterized queries ONLY	Never encode manually for SQL — always use prepared statements

Attack	Root Cause	Prevention
SQL injection	String concatenation in SQL queries	Parameterized queries / prepared statements
XSS (Cross-Site Scripting)	Unencoded user data in HTML output	Context-specific output encoding; Content Security Policy (CSP)
Command injection	String concatenation in shell commands	Avoid shell execution; use language APIs with argument arrays
Path traversal	Unvalidated file paths from user input	Canonicalize paths; validate against an allowed base directory
LDAP injection	Unescaped user input in LDAP queries	LDAP-specific escaping functions; parameterized LDAP queries
XML injection	Inline construction of XML from user data	Use XML serialization libraries; disable external entities (XXE)

Framework	Built-in Protection
React	JSX auto-escapes embedded expressions by default; beware `dangerouslySetInnerHTML`
Angular	Template expressions are auto-sanitized; beware `bypassSecurityTrust*` methods
ASP.NET	Razor views auto-encode output by default; beware `Html.Raw()`
Django	Template engine auto-escapes variables by default; beware `
Spring	Thymeleaf auto-encodes with `th:text`; beware `th:utext` (unescaped)

-- Correct: parameterized query
SELECT * FROM users WHERE email = @Email AND status = @Status;

-- WRONG: string concatenation
SELECT * FROM users WHERE email = '" + email + "' AND status = '" + status + "';

// Correct: LINQ query — parameterized automatically
var user = context.Users
    .Where(u => u.Email == email && u.Status == status)
    .FirstOrDefault();

# Correct: ORM query — parameterized automatically
user = session.query(User).filter(
    User.email == email,
    User.status == status
).first()