SQL-injection är en sårbarhet där en angripare infogar skadlig SQL genom användarinmatning — manipulerar databasfrågor för att stjäla data, kringgå autentisering eller skada data. Det är en av de farligaste och klassiska webbsårbarheterna, men kan förebyggas med rätt tekniker.
When user input is concatenated directly into a SQL query, an attacker can INJECT SQL:
query = ;
Angriparens inmatning tolkas som SQL-kod snarare än data — vilket låter dem skriva om frågan (kringgå inloggning, dumpa all data, ta bort tabeller).
// ✅ PARAMETERIZED / PREPARED statements — input is treated as DATA, never as code
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userInput]); // the value is safely bound, not concatenated
// → the database treats userInput as a literal value → injection impossible
Parameteriserade frågor (förberedda statement) separerar SQL-kod från data — inmatningen kan aldrig tolkas som SQL. Detta är det primära, pålitliga försvarssättet.
✓ PARAMETERIZED queries / prepared statements → the #1 fix (always use them)
✓ ORMs/query builders → use parameterization under the hood (but don't bypass with raw
string concatenation)
✓ INPUT VALIDATION (defense in depth) — validate/sanitize, but NOT a substitute for
parameterization
✓ LEAST PRIVILEGE DB accounts (limit damage); avoid exposing detailed DB errors
→ NEVER build queries by concatenating user input.
Att förstå SQL-injection och hur man förhindrar det är väsentligt eftersom det är en av de farligaste, klassiska och vanligaste webbsårbarheterna (del av OWASP-injektionskategorin), men helt förhindbar, så det är måste-kunskap för alla utvecklare som arbetar med databaser.
Att förstå hur det fungerar — att konkatenering av användarinmatning direkt i SQL-frågor låter en angripare injicera SQL-kod (deras inmatning tolkas som kod snarare än data), vilket möjliggör kringgåing av autentisering (' OR '1'='1), dumping av all data eller till och med borttagning av tabeller ('; DROP TABLE) — är nödvändigt för att känna igen och undvika sårbarheten.
SQL-injection kan vara katastrofal (fullständig dataintrång, dataförstöring, autentiseringskringgåing), vilket gör den kritiskt viktig.
Att förstå förebyggandet är väsentligt: parameteriserade frågor (förberedda statement) är det primära, pålitliga fixet — de separerar SQL-kod från data så användarinmatning behandlas som ett bokstavligt värde som aldrig kan tolkas som SQL, vilket gör injection omöjligt.
Detta är försvaret nummer 1 som varje utvecklare måste använda.
Att förstå de ytterligare försvaren — att använda ORM:er/frågbyggare (som parameteriserar, men inte genom att kringgå dem med rå konkatenering), indatavalidering som försvar-på-djupet (men inte som ersättning för parameterisering), minsta-behörighetsdatakonton och att undvika detaljerad felexponering — och den kardinala regeln att aldrig konkatenera användarinmatning i frågor återspeglar omfattande förebyggande.
Därför att SQL-injection är en farlig, vanlig och klassisk sårbarhet med allvarliga följder (dataintrång, dataförlust, autentiseringskringgåing) som är helt förhindbar med parameteriserade frågor, och därför att förståelse för hur det fungerar och hur man förhindrar det är väsentligt för alla utvecklare som arbetar med databaser, är förståelse för SQL-injection och dess förebyggande väsentlig, måste-kunskap — en grundläggande sårbarhet att förstå och försvara sig mot, där det enkla, pålitliga fixet (parameteriserade frågor) är kritisk kunskap som förhindrar en av de mest skadliga klasserna av attacker.