The absolute rule to trust internal and database data can bypass necessary validation
Source references: 3The document calls for validation at system edges, but also says to trust internal code and not validate data from the application's own database. This equates origin with trustworthiness; invalid or tainted data already stored may receive no later checks.
A system following this rule could use malformed fields, malicious text, or stale-schema data in rendering, authorization, or other business decisions. Depending on usage, this could cause injection, incorrect authorization, or service failures.
The skill explicitly treats internal code and data read from the application's own database as not needing validation. Boundary validation is a reasonable default, but stored data can violate current constraints after legacy writes, faulty migrations, direct writes, or earlier bugs. Code following this absolute rule could trust polluted values and make incorrect authorization, rendering, or business decisions. Users can ask the author to make this invariant- and risk-based, retaining checks for sensitive operations, database reads, and schema migrations.
### 3. Validate at BoundariesTrust internal code. Validate at system edges where external input enters:Show 2 other places
Where validation does NOT belong:- Between internal functions that share type contracts- In utility functions called by already-validated code- On data that just came from your own databaseWhere validation belongs:- API route handlers (user input)- Form submission handlers (user input)- External service response parsing (third-party data -- **always treat as untrusted**)- Environment variable loading (configuration)> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.