A human-resources portal lets employees search benefit records, attach documents and claim an annual training allowance. Three defects appear during a security review. Search input is combined directly with a database query. A free-text comment is displayed in another user’s browser without safe rendering. Two simultaneous allowance requests sometimes claim the same remaining balance. All three involve application trust boundaries, but they are not the same vulnerability and they cannot be corrected with one generic input filter.<\/p>\n
CompTIA Security+ SY0-701<\/a> terminology is useful when it helps an administrator explain the defective boundary, the affected confidentiality, integrity or availability property, and how to confirm a repair. A vulnerability is a condition that could be misused; an exploit is an attempt to use it, and evidence of actual compromise needs further investigation. The following portal is illustrative. Any security testing should be performed on authorized, disposable environments, not against a real employee service.<\/p>\n In the portal’s benefit search, the dangerous design is treating a search string as part of executable database syntax. A web application should define the intended query structure independently of the input, then bind user-supplied values as data under the database driver’s supported parameter mechanism. Prepared statements and parameterized queries are central recommendations in the OWASP SQL injection prevention guidance<\/a>.<\/p>\n For example, a legitimate search requests records from a specific department. The server should enforce the current employee’s authorization scope and pass the department name as a bound value, not assemble an SQL command by joining untrusted text. Escaping strings manually is brittle and should not replace supported parameter binding. Where dynamic identifiers such as a selected sort column cannot be bound as ordinary values, use a small allowlist of supported choices instead of accepting arbitrary names from a request.<\/p>\n Even a safely parameterized query can disclose records if it does not include correct application authorization. A logged-in user must not be able to retrieve another employee’s private benefits simply by submitting a different identifier. Separate SQL injection prevention from broken object-level authorization<\/em>: the first protects query interpretation, while the second controls which rows the principal is permitted to see or change.<\/p>\n Test the expected operation and its rejection path in a nonproduction environment. A permitted employee search should return only authorized records. Invalid or unexpected values should be handled as data or rejected by an explicit validation rule without exposing the query, database errors or secrets. A database exception logged by an application may indicate a fault, but it does not by itself prove an attacker succeeded.<\/p>\n The portal allows employees to leave comments about a training session. If one person’s text is inserted into another person’s page in a way that the browser interprets as active content, a cross-site scripting (XSS) weakness may result. Reflected XSS can involve an immediate response, stored XSS can persist through saved content, and DOM-based XSS can arise from unsafe client-side manipulation. The common design error is allowing untrusted values to cross into an executable browser context.<\/p>\nProtect the database boundary with parameterized operations<\/h2>\n
Render untrusted content as data, not browser instructions<\/h2>\n