Developers are hardening the city's online payments site against injection and session theft. Which application-security pairing is most relevant?
Select an answer to reveal the explanation.
Short Explanation
The payments site needs a bouncer at the door and a lock on the session cookie. Validate what users send in, and mark cookies Secure/HttpOnly so browsers do not casually leak them. Turning off HTTPS or auth is the opposite of hardening.
Full Explanation
Municipal payments applications sit at the intersection of injection risk and session hijacking risk. Input validation constrains what the application accepts so malformed or malicious payloads cannot drive SQL injection, command injection, or business-logic abuse in fee and citation flows. Secure cookie attributes—especially Secure and HttpOnly—keep session identifiers on HTTPS only and out of reach of client-side scripts, reducing theft via eavesdropping or XSS. Together they harden both the request path and the session artifact citizens’ browsers carry after login. Disabling HTTPS so cookies travel in cleartext for debugging exposes payment sessions to anyone on the path and contradicts basic transport security. Trusting all client-side input and storing cookies without Secure or HttpOnly flags invites injection and script-based theft. Removing authentication entirely to simplify checkout abandons identity assurance on money movement—an unacceptable trade for civic payment portals. Exam caveat: application security stems often bundle input validation with cookie flags; both matter, and neither replaces TLS. Operational check: review the payments app for server-side validation on every trust boundary, confirm cookies set Secure and HttpOnly (and SameSite where appropriate), and verify HTTPS is mandatory end-to-end in staging before release.