diff --git a/2017/en/0xa1-injection.md b/2017/en/0xa1-injection.md
index 305b4f3e8..93c1a0ec0 100644
--- a/2017/en/0xa1-injection.md
+++ b/2017/en/0xa1-injection.md
@@ -23,7 +23,6 @@ Preventing injection requires keeping data separate from commands and queries.
 * The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs). **Note**: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
 * Use positive or "whitelist" server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
 * For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. **Note**: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
-* Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
 
 ## Example Attack Scenarios
 
diff --git a/2021/docs/A03_2021-Injection.md b/2021/docs/A03_2021-Injection.md
index 834c83249..5dc831f18 100644
--- a/2021/docs/A03_2021-Injection.md
+++ b/2021/docs/A03_2021-Injection.md
@@ -62,9 +62,6 @@ Preventing injection requires keeping data separate from commands and queries:
     cannot be escaped, and thus user-supplied structure names are
     dangerous. This is a common issue in report-writing software.
 
--   Use LIMIT and other SQL controls within queries to prevent mass
-    disclosure of records in case of SQL injection.
-
 ## Example Attack Scenarios
 
 **Scenario #1:** An application uses untrusted data in the construction