From a short lunch-and-learn session at ConstructConnect: A discussion on why it's important for testers to understand trust boundaries in the systems we work with.
Input processing is complex and expensive. We can't (and shouldn't) do that in every single part of a system, so it's critical to work with developers/architects to create and understand system boundaries. This makes our testing much more effective as we know where to concentrate our efforts.
This L&L session was interactive, so I posed a bunch of questions to get responses, then guided some discussion around what trust boundaries might look like.
Trusted System Boundaries
Learn On the Go 11/2/2022
What Do We Test for Input?
• Is the item in the catalog
• JS injection / other malicious eg sql injection
• Cookies and token—auth
• Boundary failures
• Authenticity—is correct input in correct field? (cross-wire fields)
• Correct character set (Latin-1, e.g.)
• Rejecting binary input in text
• Max/min length (also a boundary)
• Blanks or zero (no input given)
What’s involved in building safe code and
• Build protection into code
• Cross-browser support
• Design impact (both UI and system)
• Complexity, effort
• Toolsets, frameworks, and libraries
System Diagram in Miro
Endpoints / Services Data Access Layer (DAL)
What do we need to work with these
• Do we know the critical flows? What APIs are called for what reasons?
• Clarity of each APIs params, etc.
• What each field means
• Each field’s limits/boundaries and data types