Skip to content

Commit 36795aa

Browse files
authoredJan 27, 2025··
Update SQL Injection Web security documentation to the best practices. (#37806)
1 parent b23adcb commit 36795aa

File tree

1 file changed

+9
-11
lines changed
  • files/en-us/learn_web_development/extensions/server-side/first_steps/website_security

1 file changed

+9
-11
lines changed
 

‎files/en-us/learn_web_development/extensions/server-side/first_steps/website_security/index.md

+9-11
Original file line numberDiff line numberDiff line change
@@ -69,7 +69,7 @@ SQL injection types include Error-based SQL injection, SQL injection based on bo
6969

7070
This vulnerability is present if user input that is passed to an underlying SQL statement can change the meaning of the statement. For example, the following code is intended to list all users with a particular name (`userName`) that has been supplied from an HTML form:
7171

72-
```sql
72+
```python
7373
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
7474
```
7575

@@ -81,21 +81,19 @@ SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WH
8181

8282
The modified statement creates a valid SQL statement that deletes the `users` table and selects all data from the `userinfo` table (which reveals the information of every user). This works because the first part of the injected text (`a';`) completes the original statement.
8383

84-
To avoid this sort of attack, you must ensure that any user data that is passed to an SQL query cannot change the nature of the query. One way to do this is to [escape](https://en.wikipedia.org/wiki/Escape_character) all the characters in the user input that have a special meaning in SQL.
85-
86-
> [!NOTE]
87-
> The SQL statement treats the **'** character as the beginning and end of a string literal. By putting a backslash in front of this character (**\\'**), we escape the symbol, and tell SQL to instead treat it as a character (just a part of the string).
88-
89-
In the following statement, we escape the **'** character. The SQL will now interpret the name as the whole string in bold (which is a very odd name indeed, but not harmful).
84+
To avoid such attacks, the best practice is to use parameterized queries (prepared statements). This approach ensures that the user input is treated as a string of data rather than executable SQL, so that the user cannot abuse special SQL syntax characters to generate unintended SQL statements. The following is an example:
9085

9186
```sql
92-
SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';
87+
SELECT * FROM users WHERE name = ? AND password = ?;
9388
```
9489

95-
Web frameworks will often take care of the character escaping for you. Django, for example, ensures that any user-data passed to querysets (model queries) is escaped.
90+
When executing the above query, for example, in Python, we pass the `name` and `password` as parameters, as shown below.
9691

97-
> [!NOTE]
98-
> This section draws heavily on the information in [Wikipedia here](https://en.wikipedia.org/wiki/SQL_injection).
92+
```python
93+
cursor.execute("SELECT * FROM users WHERE name = ? AND password = ?", (name, password))
94+
```
95+
96+
Libraries often provide well-abstracted APIs that handle SQL injection protection for the developer, such as Django's models. You can avoid SQL injection by using encapsulated APIs rather than directly writing raw SQL.
9997

10098
### Cross-Site Request Forgery (CSRF)
10199

0 commit comments

Comments
 (0)
Please sign in to comment.