top of page
Search

Uge 35: OWASP Top 10

  • Writer: Kenneth H Sørensen
    Kenneth H Sørensen
  • Sep 2
  • 12 min read
ree


De mest udbredte trusler


For at kunne bygge sikre IT-løsninger, må man først forstå, hvilke trusler man står overfor.


OWASP

Open Worldwide Application Security Project


Er en organisation der arbejder for at forbedre IT-sikkerhed i software. Organisation gør deres værktøjer og materialer tilgængelig for alle gennem open source projekter.


OWASP Projekter

  • OWASP Top 10:2021 - dok om de mest kritiske sikkerhedsrisikoer ved webapplikationer

  • OWASP API Security Top 10:2023 - dok om sårbarheder og sikkerhedsrisikoer ved API'er

  • ...


Jeg vil gennemgå de mest udbredte trusler i webapplikationer (OWASP Top 10:2021) som grundlag for videre læring.

En ny Top 10 udkommer i slutningen af 2025. Jeg vil senere på semesteret undersøge om trusselsbilledet har ændret sig.


I næste uge (Uge 36) vil jeg se på OWASP API Security Top 10:2023, da den også er relevant for vores semesterprojekt og mine valgfalg (Backend-udvikling & API-design og IT-sikkerhed).



Web Application Security


OWASP Top 10:2021

Ændringer af navne, scope samt rangering af truslerne i kategorierne fra 2017 til 2021
Ændringer af navne, scope samt rangering af truslerne i kategorierne fra 2017 til 2021


Broken Acces Control (A01:2021)


Access Control

  • Sikrer at brugere kun kan handle inden for deres tilsigtede rettigheder (autoriseret)

Broken Access Control

  • Kan betyder at information eksponeres, modificeres, bliver ødelagt eller at en bruger handler uden for sine privilegier (uautoriseret)


Typiske sårbarheder

  • Løs adgangskontrol - brud på Least Privilege / Deny by default principper

  • Adgangskontrol forbigås - ændring af URL, state, HTML-side eller API-request

  • Mulighed for at se/redigere andres konto via forudsigelige ID - Insecure Object Ref.

  • Manglende adgangskontrol til API-metoderne POST, PUT, DELETE

  • Elevering af privilegier - f.eks. rolle (uautoriseret)

  • Metadata manipulering - Ændring/misbrug af JSON Web Token (JWT) access control token, cookies eller hidden fields (HTML input field)

  • CORS fejl - API tilgængelig fra uautoriseret domæner

  • Force browsing - Adgang til beskyttede sider / admin-sider uden privilegie


Undgås ved

  • Server-side adgangskontrol - server-side eller API (ikke klienten)

  • Deny by default - alt der ikke er offentlig ressource (giv eksplicitte tilladelser)

  • Central adgangskontrol - én adgangskontrol som genbruges i applikationen samt minimal brug af CORS (Cross-Origin Resource Sharing)

  • Record ownership - tjek at bruger kun kan tilgå (CRUD) egne data

  • Håndhævelse af forretningsregler - i classes / services, IKKE kun UI eller klienten

  • Korrekt web server konfig - slå directory listing fra, og undgå følsomme filer i web roots

  • Logging af access control fejl - alarm ved gentagne fejl

  • Rate limit API og controller kald - begræns automatiserede angreb

  • Sessions og tokens - invalider session-ID ved logout og gør JWT kortlivet

    (hvis JWT er længerelevende, så følg OAuth standarder for at kunne tilbagekalde adgang)



Cryptographic Failures (A02:2021)

Sensititive Data Exposure fra 2017


Kryptering

  • Beskytter følsomme data i transit (under transport) og i hvile (lagret)


Cryptographic Failures

  • Kan betyde at følsomme data eksponeres eller system kompromitteres


Typiske sårbarheder

  • Klartekst data i transit - HTTP, FTP, SMTP eller intern trafik uden TLS (Transport Layer Sec.)

  • Svage/forældede algoritmer eller protokoller

  • Dårlig nøglehåndtering - hardcoded passwords, genbrugte/svage nøgler, manglende rotation eller pushed til GitHub

  • Manglende håndhævelse af kryptering - HTTP headers der tvinger HTTPS (f.eks HSTS)

  • Ignorerede / usikre initialization vectors (VI) - samme besked krypteres ens

    dvs. samme input = samme output

  • Passwords brugt som nøgler - for svage uden Password Base Key Derivation Function (PBKDF2). Crypto-nøgler er lange, tilfældige og svære at gætte

  • Svag randomness - nøgler, IV'er og session tokens kræver tilfældige tal, svære at gætte

  • Forældede hashfunktioner - f.eks. er MD5 og SHA1 er ikke længere sikre

  • Forældede padding-metoder - fejl i padding kan angribes

    Når data ikke fylder en hel blokstørrelse (128 bit) skal den fyldes ("paddes")

  • Kryptografiske fejl meddelelser - Utilsigtet afsløring af information

    • responstid (timing angreb)

    • fejlmeddelelser (padding oracle attack)


Undgås ved

  • Klassificering af data - hvilken data kræver kryptering / er følsom (eks.: kortnummer)

  • Undgå at gemme unødig data - slet hurtigst muligt, tokenisering eller truncation af data

  • Krypter data i hvile - følsomme data, filer og backups i databaser (DB) krypteres

  • Brug stærke algoritmer, protokoller og nøgler (+ korrekt håndtering)

  • Krypter data i transit - protokoller som TLS. Håndhæv kryptering med direktiver som HTTP Strict Transport Security (HSTS)

  • Undgå caching af følsom data

  • Implementering af sikkerhedskontroller afhængig af klassificering - se første punkt

  • Undgå forældede protokoller til transport af følsom data - FTP og SMTP

  • Password hashfunktioner - gem passwords ved brug af adaptive hashing og salt med work factor (Argon2, scrypt, bcrypt, PBKDF2)

  • Brug initialization vector (VI) korrekt - generér med CSPRNG, brug ikke samme IV to gange til samme nøgle

  • Authenticated encryption - kryptering med integritetskontrol

    dvs. verificering af integritet / tjek at data er uændret

  • Sikker nøglegenerering - kryptografisk, random, gem i byte arrays (ikke strings) hvis password bruges og konverter via key derivation

  • Stærk randomness - brug kryptografisk tilfældighed hvor der behov (CSPRNG) undgå forudsigelige seeds / lav entropi

  • Undgå forældede hashfunktioner og padding-metoder - MD5 og SHA1...

  • Test effektiviteten af konfiguration og settings



Injection (A03:2021)

Inkluderer Cross-Site Scripting (XSS) fra 2017


Injection

  • Når brugerdata bruges direkte i kommandoer eller queries uden korrekt validering, filtrering eller escaping.

    Kan føre til eksponering, ændring eller sletning af data samt kompromittering af hele systemet


Typiske sårbarheder

  • Manglende validering, filtrering og sanitering af input - eks.: forventer id som heltal, men accepterer tegn

1 OR 1=1

  • Dynamiske queries / ikke-parametriserede kald - brugerinput blandes med kode og fortolkes som en del af kommandoen

var q = "SELECT * FROM Users WHERE id = " + userInput; // ikke-param query
db.Execute(q); // direkte til SQL-interpreter fortolker både kode + input

  • ORM-injection - ondsindet data i ORM-parametre kan udvide søgning og udtrække ekstra records (Object Relational Mapper f.eks Entity Framework)

// farligt  -  bruger skriver: ' OR 1=1 --  
var users = await db.Users
	.FromSqlRaw($"SELECT * FROM Users WHERE Name = '{input}'") 
	.ToListAsync();

// sikkert -  input sendes som parameter
var users = await db.Users
	.FromSqlInterpolated($"SELECT * FROM Users WHERE Name = {input}");
	.ToListAsync();

  • Sammenkædning af brugerinput med SQL eller kommandoer (concat i dynamic queries, commands, stored procedures)

SET @sql = 'SELECT * FROM Users WHERE id = ' + @userInput; 
EXEC(@sql);  -- concat i stored procedure = sårbar

  • Almindelige injection-typer:

    • SQL, NoSQL, OS Command, ORM, LDAP, Expression Language (EL), OGNL


  • XSS (Cross-Site Scripting) - giver angriber adgang kodekørsel i brugerens browser

    (kan stjæle cookies/sessioner, manipulere DOM)


Undgås ved

  • Seperation af inputdata, kommandoer og queries


  • Brug sikre API’er eller framwork - metoder/biblioteker holder data og kommando adskilt

    ADO.NET (C#)

var cmd = new SqlCommand("SELECT * FROM Users WHERE Name = @name", conn);
cmd.Parameters.AddWithValue("@name", input);

Entity Framework Core (C# / LINQ / ORM)

var users = db.Users.Where(u => u.Name == input).ToList();

  • Stored procedures - parameteriserede kald, ingen dynamisk kald (concat)

  • Positiv server-side inputvalidering - whitelist frem for blacklist (extra ikke erstatning)

  • Escaping - hvis bygning af streng er absolut nødvendig, neutralisér specialtegn

  • Struktur-navne (tabel, kolonne osv.) må aldrig komme fra brugerinput

  • Automatiseret test - af alle parametre, headers, URL, cookies, API-payloads: JSON, SOAP, XML

  • Integrér SAST, DAST og IAST i CI/CD - find injection-fejl inden produktion

    • SAST: Statisk kildekodeanalyse før kørsel - finder concat-mønstre, usikre API-kald

    • DAST: Dynamisk black-box test mod kørende app  - prøver reelle payloads

    • IAST: Sensor i app under test  - ser hvilke linjer der rammes af ondsindet input




Insecure Design   (A04:2021)

Ny kategori 2021


Insecure Design

  • Opstår når systemet er bygget med design- eller arkitekturfejl

    Kan ikke rettes med perfekt kode, fordi kontrollerne aldrig blev tænkt ind fra start.


Typiske sårbarheder

  • Fejl i design (ikke koden) - sikkerhedskontroller fraværende / forkerte (eks. lockout, 2FA..)

  • Ingen trusselsmodellering - systemets flows / data er ikke analyseret ift. angreb

    (eks. skadelige filtyper..)

  • Manglende forretningslogik-beskyttelse - f.eks ingen begrænsning på antal bookinger/køb

  • Svage credential-flows - usikre password recovery-metoder (eks. Q&A er ikke et sikkert identitetsbevis)

  • Ingen anti-bot eller rate limiting - systemet kan misbruges af scripts eller scalpers

  • Ubeskyttede grænser - tillid til client-side checks eller manglende tenant-separation

    (eks. kun validering i browser og kunde A kan se kunde B's data)


Undgås ved

  • Secure Development Lifecycle - indbyg sikkerhed fra start (med AppSec specialister)

  • Brug af secure design patterns - genbrug allerede velprøvede komponenter og arkitekturer

  • Trusselsmodellering - især på auth, adgangskontrol, forretningslogik og kritiske flows

  • Sikkerhed i user stories - inkluder sikkerhedskrav og failure flows

  • Plausibility checks - valider input og processer på alle lag (frontend, backend, DB)

    (eks. bestilling af et negativt antal billetter)

  • Tests mod trusselsmodeller - unit/integration tests af kendte angreb/misbrug af flows

    (eks. bestilling af 600 biografbilletter)

  • Segregation - adskil tenants i alle systemlag

  • Ressourcebegrænsning - sæt limits på ressourceforbrug pr. bruger/service



Security Misconfiguration   (A05:2021)

Inkluderer XML External Entities (XXE) fra 2017


Security Misconfiguration

  • Når systemer er forkert konfigureret eller mangler hardening / hærdning af indstillinger.

    Kan betyde eksponering af data og systemkompromittering.


Typiske sårbarheder

  • Manglende hardening - system, framework eller cloud-tjeneste ikke konfig / sikret korrekt

  • Unødvendige features - åbne porte, services, konti, privilegier

  • Default accounts/passwords - indstillinger ikke ændret

  • Fejlmeddelser - detaljerede fejl/stack traces vises til brugere

  • Manglende aktivering af sikkerhedsfunktioner (ofte efter opgraderinger)

  • Usikre server/framework indstillinger - f.eks i ASP.NET, biblioteker og databaser

  • Manglende security headers - HTTP-responses uden sikre direktiver

    (eks. HSTS, CSP, X-Frame-Options ...)

  • IKKE-opdateret software - se Vulnerable & Outdated Components nedenfor


Undgås ved

  • Hardening-processer - gentagelig, automatiseret opsætning af sikre miljøer

    (Dev, QA, Prod)

  • Minimal platform - fjern unødvendige komponenter, services, dokumentation og frameworks

  • Patch management - hold configs og software opdateret, inkl. cloud-permissions

    (eks. S3 buckets)

  • Segmentation/Isolation - adskil komponenter og tenants (ACLs, containerization, netværkssegmenter)

  • Security headers - send sikre direktiver til klienter (HSTS, CSP, X-Content-Type-Options ...)

  • Automatiseret validering - scripts/scans der tjekker configs løbende i alle miljøer



Vulnerable and Outdated Components   (A06:2021)


Vulnerable and Outdated Components

  • Når software, frameworks eller biblioteker er sårbare, forældede eller ikke vedligeholdes.

    Sårbarheder i komponenter kan give samme rettigheder som applikationen selv.


Typiske sårbarheder

  • Manglende overblik - ift. versioner af komponenter (server- og client-side)

  • Forældet / sårbar / unsupported software  - operativsystemer (OS), web-/applikationsserver, database management system (DBMS), applikationer, API'er, runtime environments, frameworks og biblioteker

  • Ingen scanning  - ingen regelmæssige vulnerability scans eller overvågning af:

    • CVEs/NVD relateret til komponenter som benyttes

      (Common vulnerability and Exposures / National Vulnerability Database)

  • Langsom patch-proces  - unødig eksponeringsvindue for angreb

  • Manglende patch-proces - kompatibilitetstest og benyttelse af opdaterede biblioteker

    (ældre libraries har muligvis sårbarheder)

  • Usikre konfigurationer  - se Security Misconfiguration ovenfor


Undgås ved

  • Patch management  - hurtig proces for opdateringer og fjernelse af ubrugte komponenter

  • Inventar og overvågning  - kend versioner af alle dependencies (client/server) og hold øje med CVEs/NVD

    • Software Composition Analysis (SCA)  - automatisér med værktøjer (Dependency Check, retire.js, GitHub advisories)

  • Kun officielle kilder  - hent komponenter fra trusted sources via sikre links, foretræk signed packages

  • Overvåg vedligeholdelse  - brug ikke libraries uden aktiv patching, hvis uundgåeligt, brug “virtual patching” (WAF, IDS)

  • Langsigtet plan  - kontinuerlig monitorering, triagering (vurder alvorlighed) og opdatering gennem hele app'ens livscyklus



Identification and Authentication Failures    (A07:2021)

Tidligere Broken Authentication (2017)


Identification and Authentication Failures

Når brugeridentitet, login eller sessioner ikke håndteres sikkert.

Kan føre til kontoovertagelse, credential reuse, brute force eller session hijacking.


Typiske sårbarheder

  • Automatiserede angreb - credential stuffing med lister af brugernavne/passwords

  • Brute force  - ingen begrænsning på antal loginforsøg

  • Svage/default passwords  - f.eks “Password1” eller “admin”

  • Usikre credential recovery flows  - Q&A (ikke et sikkert identitetsbevis)

  • Svag password storage  - passwords gemt i klartekst, svagt krypteret eller hashed uden salt

  • Manglende MFA  - ingen eller ineffektiv multi-factor authentication

  • Session ID i URL  - gør det nemt at opsnappe og misbruge sessionen

  • Session reuse  - samme session-ID genbruges efter login (betyder andre kan genbruge)

  • Manglende session invalidation  - sessioner/tokens udløber ikke korrekt ved logout eller inaktivitet


Undgås ved

  • Multi-factor authentication  - bevis for identitet beskytter mod credential stuffing, brute force og reuse

  • Ingen default credentials  - fjern fabriksindstillinger, især for admin-konti (admin/admin)

  • Weak password checks  - afvis passwords fra lister over de mest brugte (f.eks top 10.000)

  • Moderne password-politikker  - følg NIST 800-63b mht. længde, kompleksitet, rotation osv.

    (National Institute of Standards and Technology)

  • Hærdede credential flows  - brug samme fejlmeddelelse for at undgå account enumeration angreb

  • Rate limiting / delay  - begræns eller forsink gentagne loginforsøg, log hændelser og alarmer ved mistænkelig aktivitet

  • Sikker session management  - brug server-side session manager, generér nyt tilfældigt session-ID efter login, aldrig i URL, invalider ved logout, inaktivitet og timeouts



Software and Data Integrity Failures   (A08:2021)

Ny kategori 2021

Inkluderer Insecure Deserialization 2017


Software and Data Integrity Failures

Handler om situationer, hvor kode eller infrastruktur ikke har mekanismer til at sikre integritet.

Kan føre til ondsindet kode, kompromitterede opdateringer eller manipulation af data.


Typiske sårbarheder

  • En applikation kan blive sårbar, hvis den stoler på kode eller komponenter fra kilder, den ikke kan verificere

    • Tredjeparts-komponenter fra usikre kilder - plugins, libraries eller modules hentet fra uofficielle repos (NuGet, npm, Maven osv.) hvor pakker kan være manipuleret (f.eks typo-squatting)

    • Content Delivery Networks (CDNs)  - loader scripts direkte fra eksternt CDN uden integritetstjek (f.eks <script src="...">)

  • Auto-updates uden verificering  - app henter opdateringer uden at tjekke digital signatur

    • angriber kan erstatte med ondsindet kode

  • Insecure CI/CD pipeline  - manglende adgangskontrol/isolation i build- og deploy-pipelines

    • angriber kan manipulere udviklers commit og injicere ondsindet kode eller config

  • Insecure deserialization

    • serialized objekter/data sendes til klienten uden signatur/validering

    • klient kan manipulere og sende tilbage

    • risiko for code execution eller data manipulation


Undgås ved

  • Digital signatur / integritetstjek  - verificér at software/data kommer fra forventet kilde og ikke er ændret

  • Trusted repositories  - hent libraries fra officielle kilder

    Hvis virksomhed har høj risikoprofil brug intern vetted repo

  • Supply chain security tools  - f.eks OWASP Dependency Check, CycloneDX, SCA-værktøjer til afhængighedskontrol (Software Composition Analysis)

  • Code & config review  - Find og forhindre ondsindet kode eller config-fejl i pipelines

  • Sikker CI/CD pipeline  - korrekt segregation, konfiguration og adgangskontrol i build/deploy-processer

  • Sikker serialization  - send ikke serialized data til klienter uden et integritetstjek, f.eks digital signatur



Security Logging and Monitoering Failures   (A09:2021)

Tidligere Insufficient Logging and Monitoring 2017


Security Logging and Monitoring Failures

Handler om manglende evne til at opdage, eskalere og reagere på aktive brud.

Kan føre til at angreb ikke opdages, og at hændelser ikke kan spores eller efterforskes.


Typiske sårbarheder

  • Manglende logging  - vigtige events (logins, mislykkedes logins, transaktioner) logges ikke

  • Dårlige logmeddelelser  - advarsler og fejl giver uklare eller utilstrækkelige logs

  • Manglende overvågning  - logs fra apps og API'er bliver ikke analyseret for mistænkelig aktivitet

  • Lokale logs  - logs gemmes kun lokalt og kan let slettes, manipuleres eller gå tabt

  • Ingen effektiv alarmering og eskalering  - manglende tærskler for hændelser og procedurer for eskalering for at kunne reagere på angreb i tide

  • Sikkerhedstest udløser ingen alarm - uopdaget pentests og DAST-scanninger (f.eks OWASP ZAP) afslører at reelle angreb også vil passere ubemærket

  • Ingen real-time detection  - app kan ikke opdage og advare om aktive angreb

  • Information lækage i logs  - brugere/angribere kan se log- og alarmdata

  • Log injection  - brugerinput logges uden korrekt encoding, så angribere kan indsætte falske poster og skjule deres aktivitet


Undgås ved

  • Logging af kritiske hændelser  - log login, adgangskontrol og valideringsfejl med kontekst nok til at identificere angribere

  • Standardiseret logformat  - så logs kan læses af log management-løsninger

  • Korrekt encoding af logdata  - undgå log injection og misbrug af logsystemet

  • Audit trail på værdifulde transaktioner  - f.eks append-only databaser eller integritetskontroller, så logs ikke kan ændres

  • Effektiv overvågning og alarmering  - DevSecOps sikrer hurtig detektion og respons på mistænkelig aktivitet

  • Incident response plan  - etabler eller brug en plan som NIST 800-61r2 til håndtering og genopretning

  • Værktøjer  - f.eks OWASP ModSecurity Core Rule Set eller ELK-stack til logkorrelation, dashboards og alarmering



Server Side Request Forgery (SSRF)    (A10:2021)

Ny kategori 2021


SSRF

Sårbarhed opstår når applikation henter ressourcer fra en bruger angivet URL uden validering.

Angriber kan tvinge serveren til at sende requests til uventede destinationer - også bag firewalls og virtual private network (VPN) / network access control list (ACLs).


Typiske sårbarheder

  • User-angivet URL uden validering - app accepterer blindt URL (f.eks billedupload). Angriber kan få server til at hente ressourcer den ikke burde

  • Ingen begrænsning af skema/port/destination - uden whitelist kan angriber tilgå interne services eller følsomme filer

  • HTTP-redirects slået til - requests kan omdirigeres til ondsindede mål

  • DNS-rebinding / TOCTOU-angreb - udnytter forskel mellem valideringstidspunkt af URL og faktisk brug af URL

  • Dårlige “deny lists” - regex/blacklists kan let omgås med alternative payloads

  • Manglende netværkssegmentering - server kan nå ALLE interne ressourcer


Undgås ved

Netværkslag

  • Segmentér adgangen til eksterne ressourcer - isolér funktioner, der laver udgående kald

  • Deny by default-firewalls - bloker alt internt trafik, tillad kun nødvendige forbindelser

  • Lifecycle for firewall regler - ejerskab, opdatering og logging af alle regler


Applikationslag

  • Valider input - sanitér og verificér at URL'er følger whitelist af skema (http/https),

    port (80/443), hosts/domæner (tilladte destinationer)

  • Ingen rå responses - returnér ikke ukontrollerede svar direkte til klienten

  • Deaktiver redirects - følg ikke automatisk HTTP-omdirigeringer

  • Vær opmærksom på DNS-rebinding og TOCTOU - dobbelttjek konsistens mellem input og faktisk request

    • Tjek at DNS-navnet stadig peger på den samme (tilladte) IP, når requesten faktisk udføres - Ikke kun under første validering


Yderligere tiltag

  • Ingen følsomme services på frontend-systemer - f.eks OpenID eller interne API'er

  • Kontrol af lokal trafik - serveren skal ikke kunne kalde localhost og loopback-interfaces

  • VPN/netværkskryptering for særlige grupper - hvis der er meget høje krav til beskyttelse




API Security


OWASP API Security Top 10:2023


Se Uge 36



Refleksion


Ved at læse OWASP Top 10:2021 har jeg fået et overblik over de mest almindelige trusler. Derudover forstår jeg nu bedre at langt de fleste sårbarheder kommer fra design- og procesfejl.

I sidste uge (Uge 34) læste jeg om CIA Triad. Modellen er viser målene man sigter efter for et sikkert IT-system, og OWASP viser de ting der truer målene.


Så jeg skal designe med CIA Triad og validere mod OWASP. Udfordringer

Jeg har forsøgt at sætte mig ind i hvert punkt i listen, men der er mange nye udtryk. Det er gået op for mig hvor meget man egentlig kunne fordybe sig i hver sårbarhed.


Derfor kommer denne blog også til at fungere lidt som opslagsværk for mig.


Hvad har jeg opnået

Jeg var alligevel overrasket over hvor meget der gav mening. Vi har set lidt på nogen af de her ting i et tidligere semester.


I semester 3, arbejdede jeg meget med Access Control, og mere specifikt role based access control (RBAC). I den forbindelse arbejdede jeg en del med Identity i ASP.NET Core, user- / role management, JWT og CORS.


I sommerferien fik jeg startet et projekt hvor jeg bl.a. fik lært om refresh tokens, rotation af tokens, og kortlivet access tokens. Hvilket er ting der også nævnes i listen.


Så jeg har fået et større overblik og jeg kan mærke at min forståelse bliver bedre.

Videre plan


IT-sikkerhed

Med denne oversigt over OWASP Top 10 (webapplikation), har jeg lagt et fundament for videre læring. Jeg vil gerne læse en anden Top 10 også, da den kunne gå hen og vise sig at være meget relevant for vores semesterprojekt og mine valgfag. Derfor vil jeg læse

  • OWASP API Security Top 10

  • OWASP Top 10:2025 (i fremtiden)


Backend-udvikling og API-design

Jeg er startet med IT-sikkerhed og har udskudt backend lidt da jeg gerne vil leve op til

secure-by-design principperne.

Jeg vil se på microservices vs. monolith architecture og hexagonal arkitektur



Ressourcer


OWASP


Hjemmeside: OWASP Top Ten

Dokumentation: OWASP Top Ten 2021


Cloudflare - Learning Center


Artikel: What is OWASP



Evt. videre læsning


OWASP


Software Assurance Maturity Model (SAMM)


OWASP Top 10:2025



bottom of page