OWASP / CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
https://cheatsheetseries.owasp.org
Creative Commons Attribution Share Alike 4.0 International
27.08k stars 3.79k forks source link

Copy editing on SQL Injection Prevention cheat sheet #1344

Closed neurosie closed 4 months ago

neurosie commented 4 months ago

Initially I was just going to fix a typo that I noticed but I went and edited the whole page.

Notably I removed this whole section:

Language-Specific Recommendations for Prepared Statements:

--Java EE: PreparedStatement() with bind variables --.NET: Parameterized queries like SqlCommand() or OleDbCommand() with bind variables --PHP: PDO with strongly typed parameterized queries (using bindParam()) --Hibernate: createQuery() with bind variables (called named parameters in Hibernate) --SQLite: sqlite3_prepare() to create a statement object

Occasionally, prepared statements can harm performance. If this occurs, you should a) strongly validate all data or b) instead of using a prepared statement, escape all user supplied input using an escaping routine specific to your database vendor as described below.

3 out of 5 of the bullet points were redundant to other blocks in that section. There's already a link out to a longer sheet with recommendations for way more languages at the end of the prepared statement section.

As for the last sentence, I did a little research on the relationship between prepared statements and performance and it's complex, sometimes helping and sometimes hurting, with mitigations being very situation dependent. Seems bad to recommend the less secure method of input escaping when that's heavily recommended against elsewhere in this same sheet.