Skip to content

Security Input Validation And Dangerous Sinks

Pack: security Source: security/security-input-validation-and-dangerous-sinks/SKILL.md Use this skill when the risk comes from attacker-controlled input flowing into a dangerous sink.

  • input validation
  • normalization
  • parameterized database access
  • HTML and output-context encoding
  • shell, path, redirect, and URL sink safety
  1. Name the untrusted input source.
  2. Name the dangerous sink it can reach.
  3. Validate and normalize input once near entry.
  4. Use sink-specific protection:
    • parameterized queries for SQL
    • context-appropriate escaping or encoding for HTML
    • path allowlists or fixed roots for filesystem access
    • no shell interpolation for command execution
    • redirect allowlists for outbound navigation
  5. Keep raw attacker input away from privileged sinks when possible.
  • Use richer schema validation only when the domain actually needs structured coercion or refinement.
  • Allow limited rich text only with a deliberate sanitization and rendering boundary.
  • Use raw input logs sparingly and only with redaction when sensitive data may be present.
  • Validation is not generic string cleaning.
  • Protection must match the sink, not just the input type.
  • Normalize once; avoid multiple inconsistent parsing paths.
  • Prefer avoiding dangerous sinks entirely when the feature design allows it.
  • “sanitize everything” with no sink model
  • string-concatenated SQL
  • trusting file paths or redirect targets from raw input
  • assuming one HTML sanitizer solves shell, SQL, and URL problems too
  • source input is named
  • dangerous sink is named
  • validation and normalization happen once
  • sink-specific protection is used
  • raw attacker input is not flowing unchecked into privileged operations

When answering with this skill, prefer:

  • untrusted source
  • dangerous sink
  • required validation
  • required sink-specific protection
  • main exploit path if left unchanged