Injectioneasy0-2 years
A teammate proposes fixing a SQL injection finding by escaping single quotes in the input before building the query string. Why isn't that the same fix as switching to a PreparedStatement, even if it happens to stop the specific payload the scanner flagged?
Escaping tries to make attacker data harmless inside a sentence that's still being parsed as one string — you're still handing the database one blob of text and hoping every character in it is escaped correctly for every context it might end up in. A PreparedStatement changes the shape of the problem: the SQL with ? placeholders is sent and compiled into a plan first, and only then are the values supplied separately, as data, with no parsing step left for them to influence. That's also why parameterization fixes a customer named O'Reilly for free — nobody has to remember to escape their apostrophe, because their name was never going to be parsed as SQL syntax in the first place.
PreviousAn endpoint is behind a login, uses `@PathVariable Long id`, and looks up the order by that id alone. A pen test flags it as broken. The endpoint clearly requires authentication — so what's actually broken, and why does the fix belong in the query rather than after it?Next A junior engineer proposes storing `SHA-256(password)` for a new signup flow, reasoning that SHA-256 is a secure, one-way hash. What's wrong with that reasoning, and what does the fix actually add?