Django tilbyder stærk indbygget beskyttelse mod almindelige websårbarheder (OWASP Top 10) — sikkerhed er en kerneprioritering i designet, og mange beskyttelser er aktiveret som standard. At forstå dem er afgørende for at bygge sikre applikationer og ikke ved et uheld at deaktivere disse sikkerhedsforanstaltninger.
# ✅ the ORM uses PARAMETERIZED queries automatically — safe by default
filter
# input is never executable SQL
# ⚠️ raw SQL CAN be vulnerable — always parameterize:
"SELECT * FROM users WHERE name = %s"
# ✅ parameterized
# NEVER: f"SELECT ... WHERE name = '{user_input}'" ❌ injectable
ORM'en parametriserer alle forespørgsler, hvilket forhindrer SQL injection som standard — en stor klasse af sårbarhed, der elimineres, medmindre du skriver usikker råSQL.
# settings.py — enable these in production
SECURE_SSL_REDIRECT = True# force HTTPS
SESSION_COOKIE_SECURE = True# cookies only over HTTPS
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000# HSTS — enforce HTTPS
SECURE_CONTENT_TYPE_NOSNIFF = True
Det kritiske ansvar: undermin ikke standarderne
text
⚠️ DEBUG = False in production — DEBUG=True leaks tracebacks, settings, source paths
⚠️ Keep SECRET_KEY secret (env vars, not code) — it signs sessions/tokens
⚠️ Set ALLOWED_HOSTS to prevent Host-header attacks
⚠️ Don't use |safe or mark_safe on untrusted input (reopens XSS)
⚠️ Always validate/sanitize input; use Django forms/serializers
⚠️ Run `python manage.py check --deploy` to audit production security settings
Hvorfor det betyder noget
Sikkerhed er kritisk for enhver webapplikation, og det er afgørende at forstå Djangos indbyggede beskyttelser både for at udnytte dem og for ikke ved et uheld at undermine dem — Djangos stærke sikkerhedsstandarder er en vigtig grund til, at det er betroet for seriøse applikationer, men de beskytter dig kun, hvis du forstår og respekterer dem.
Django håndterer de mest almindelige og farlige websårbarheder som standard: ORM'en forhindrer SQL injection via parametriserede forespørgsler, template auto-escaping forhindrer XSS, CSRF middleware forhindrer cross-site request forgery, clickjacking-beskyttelse er indbygget, og adgangskoder er sikkert hashede — hvilket eliminerer hele kategorier af sårbarheder, som udvikler skal håndtere manuelt (og ofte får forkert) i mindre sikkerhedsfokuserede frameworks.
At forstå disse beskyttelser er vigtig, så du ved, at de eksisterer, konfigurerer dem korrekt (især produktionssikkerhedsindstillinger for HTTPS, sikre cookies og HSTS), og — kritisk — ikke ved et uheld deaktiverer dem: de mest almindelige Django-sikkerhedsfejl kommer fra at undermine standarderne, såsom at efterlade DEBUG=True i produktion (lækker følsomme stacktraces og indstillinger til angribere), committe SECRET_KEY, bruge |safe/mark_safe på upålideligt input (genåbner XSS), skrive uparametriseret råSQL (genåbner injection), eller forkonfigurere ALLOWED_HOSTS.
At kende de beskyttelser Django tilbyder, hvordan man konfigurerer sikre produktionsindstillinger, og ansvaret for ikke at svække standarderne (plus brug af check --deploy til at revisionere) er fundamental for at bygge sikre applikationer.
Fordi webapplikationer er konstante angrebsmål, og sikkerhedsfejl kan være katastrofale (databrud, kontocompromis), er forståelse af Djangos sikkerhedsmodel — både hvad den beskytter imod automatisk og dit ansvar for at opretholde disse beskyttelser — afgørende, højindsats-viden, der afspejler professionel, sikkerhedsbevids udvikling og er et hyppigt, vigtigt emne for enhver produktionsapplikation.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.