second-order-injection-anti-pattern

A second-order injection attack occurs when malicious data is stored safely in a database but executed later in a dynamic query without re-sanitization. This separates the injection point from execution, making the payload difficult to detect during initial storage.

Prevent second-order SQL injection by auditing data flows and treating all database-retrieved data as potentially tainted. Always use parameterized queries for dynamic query construction instead of directly reusing stored data like user action logs.

Yes, you must sanitize data extracted from your own database before using it in a query. Internal storage is not inherently safe; treating all database-retrieved data as potentially tainted prevents hidden payloads from executing during subsequent dynamic query construction.

The best way to audit unsafe data reuse is tracing data flows from storage retrieval to dynamic query construction. Identify where database or log data is reused without re-sanitization, ensuring parameterized queries are enforced to prevent hidden payload execution.

Parameterized queries fail to stop second-order injection when developers safely store input but later retrieve and concatenate it into a new dynamic query without parameters. The initial safe storage creates a false sense of security against delayed execution attacks.