Prévention des injections SQL
Comprenez le fonctionnement des injections SQL et mettez en œuvre des défenses robustes à l’aide de requêtes paramétrées et d’instructions préparées.
Prévention des injections SQL est une leçon Secure Coding & OWASP Top 10 for Backend gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Secure Coding & OWASP Top 10 for Backend, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Secure Coding & OWASP Top 10 for Backend comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
What is SQL Injection?
Imagine you're talking to a database using a special language called SQL. Sometimes, bad actors can trick your application into sending unexpected SQL commands to the database.
This trick is called SQL Injection (SQLi). It happens when user input is treated as part of the SQL command itself, rather than just data.
SQLi can lead to:
- Data theft or modification
- Bypassing login screens
- Gaining control over the database server
How SQLi Works: A Login Example
Let's say a login form takes your username and password. The application might build a SQL query like this to check if you exist:
SELECT * FROM users WHERE username = 'your_username' AND password = 'your_password';
What if 'your_username' isn't just a name, but also a piece of SQL code?
The Vulnerable Code
A common mistake is building SQL queries by directly combining (concatenating) user input with the query string. Here's a simplified example in Java:
public class Main {
public static void main(String[] args) {
String username = "admin"; // User input
String password = "pass123"; // User input
// DANGEROUS: String concatenation
String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "';";
System.out.println("Executing query:\n" + query);
// In a real app, this query would go to the database.
}
}Crafting the Malicious Input
Now, imagine a malicious user enters this as their username:
admin' OR '1'='1
And any text for the password. When combined with the vulnerable query, it becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'any_password';
The OR '1'='1' part makes the condition always true, effectively bypassing the password check and logging the attacker in!
Introducing Prepared Statements
The best defense against SQL Injection is using Prepared Statements (also known as Parameterized Queries).
They separate the SQL logic from the user-provided data. Instead of directly inserting input, you use placeholders (like ?) in your query.
The database then understands that anything provided for these placeholders is pure data, not part of the command.
Prepared Statements in Action
Here's how you'd use a prepared statement to safely query for a user by their ID. Notice the ? placeholder.
public class Main {
public static void main(String[] args) {
int userId = 123; // User input
// Secure: Using a placeholder for the value
String sql = "SELECT name, email FROM users WHERE id = ?;";
// In a real application, you'd 'prepare' this SQL
// and then 'set' the parameter value (userId) separately.
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (id): " + userId);
// The database treats 'userId' as a value, not SQL code.
}
}How Parameters Prevent SQLi
When you use a prepared statement:
- Separation of concerns: The SQL query structure is sent to the database first.
- Data vs. Code: The database 'pre-compiles' the query. Then, when you provide values for the placeholders, it treats them strictly as data.
- Automatic Escaping: The database automatically handles any special characters in your input, preventing them from being interpreted as SQL commands.
This ensures that malicious input like ' OR '1'='1 cannot alter the query's intent.
Securing the Login Example
Let's fix our vulnerable login example using prepared statements. Now, even if a user tries to inject SQL, it will be treated as part of their username/password, not as a command.
public class Main {
public static void main(String[] args) {
String username = "admin' OR '1'='1"; // Malicious input
String password = "any_password"; // Malicious input
// SECURE: Using prepared statement with placeholders
String sql = "SELECT * FROM users WHERE username = ? AND password = ?;";
// Simulating how parameters are set (conceptual)
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (username): " + username);
System.out.println("Parameter 2 (password): " + password);
System.out.println("\nDatabase will look for a user with the literal username 'admin' OR '1'='1' and the given password. This user likely won't exist. Attack thwarted!");
}
}Beyond Login: All SQL Operations
Prepared statements aren't just for SELECT queries. You should use them for ALL SQL operations that involve user input:
INSERTstatements (e.g., adding a new user)UPDATEstatements (e.g., changing a user's profile)DELETEstatements (e.g., removing data)
Always assume user input is malicious until proven otherwise. Parameterized queries are your first line of defense.
Quick Check: Secure Query
Which of the following code snippets correctly uses parameterized queries to prevent SQL Injection when searching for a product by name?
Recap: SQL Injection Prevention
Great job! In this lesson, you learned about:
- What SQL Injection is and its dangers.
- How vulnerable applications can be exploited by concatenating user input directly into SQL queries.
- The importance of using Prepared Statements (Parameterized Queries) as the primary defense mechanism.
- How prepared statements separate data from code, preventing malicious input from altering query logic.
Always use prepared statements for any SQL operation involving user input to keep your backend secure!
Questions Fréquemment Posées
La leçon « Prévention des injections SQL » est-elle gratuite ?
Oui — le texte complet de « Prévention des injections SQL » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Secure Coding & OWASP Top 10 for Backend, passe à CoddyKit PRO. Le cours Secure Coding & OWASP Top 10 for Backend comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Prévention des injections SQL » ?
Comprenez le fonctionnement des injections SQL et mettez en œuvre des défenses robustes à l’aide de requêtes paramétrées et d’instructions préparées. Tu pratiques Secure Coding & OWASP Top 10 for Backend avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Secure Coding & OWASP Top 10 for Backend ?
Aucune expérience préalable n'est requise. Secure Coding & OWASP Top 10 for Backend sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.
Combien de temps prend la leçon « Prévention des injections SQL » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Secure Coding & OWASP Top 10 for Backend ?
Oui. Chaque leçon Secure Coding & OWASP Top 10 for Backend inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Prévention des injections SQL
- Injection de commandes et de code
- Cross-Site Scripting (XSS) dans le backend
- Prévenir les injections XML et LDAP