Application boundaries and secrets | Security+: security and production decisions

Concept and mechanism

SQL injection arises when client-controlled data changes query structure. Parameters for values establish the intended separation; elements such as table names or ordering need separate design and validation. Removing some quotes or hiding errors does not by itself fix unsafe construction. In the browser, XSS requires attention to the context where a value is inserted. To display text, prefer a sink that does not interpret markup. HTML, attributes, JavaScript, and URLs do not share one universal encoding rule. Client-only validation does not protect direct API calls.

Guided application

A service fetching user-supplied URLs can become a path to internal resources. For SSRF, control actual destinations, protocols, resolution, and redirects, supporting the application with network restrictions. Hiding the response does not necessarily prevent effects at the destination. Secrets form another boundary: if a valid key enters a shared repository, removal in a later commit does not revoke it. Rotate or revoke the credential, investigate usage, and update consumers. History cleanup can form part of treatment but does not replace withdrawing the exposed access capability.

IN PRACTICE

An import function should accept only business-required destinations. Its token should have limited scope and support rotation independent of the author’s personal account.

Common pitfalls

Using character filters as the only defense; applying encoding out of context; validating only URL scheme; confusing text removal with revocation.

Related topics: Architecture, privileges, and recovery · Identities, patches, logs, and assets

Take this idea with you

Validate data meaning and destination at each trust boundary.

Create account

Reference: SQL injection prevention · SY0-701 V7