Your organisation deployed MFA. Staff passed the phishing simulation. Complex passwords are mandated. Yet a category of attack your current testing almost certainly does not cover is growing across South African financial services, telecoms, retail, and healthcare. Attackers have not abandoned your authentication controls. They have simply moved past them, targeting the browser session that begins the moment authentication succeeds.
Once a user authenticates, the server issues a session token, typically stored as a browser cookie. That token is the proof of identity for every request that follows. Steal it, and you inherit the session: permissions, access level, and active context included. MFA provides no protection at this stage because MFA already fired before the token was issued.
The theft methods vary. Infostealer malware targets browser credential stores directly, and commercial infostealers have become widely accessible. Cross-site scripting (XSS) vulnerabilities extract cookies from the DOM without touching your identity provider. Adversary-in-the-browser malware reads the cookie store from the filesystem. None of these techniques require a user's password or MFA token. HP Africa's 2026 threat research identifies cookie theft as an active and growing pattern across the sectors South African enterprises operate in, and the question is not whether this technique is being used. The question is whether your current testing validates your defences against it.
Not every stolen cookie becomes a working session. Your application's session controls determine whether a captured token is usable and for how long. Three failures consistently convert cookie theft from a theoretical concern into a confirmed breach path.
Weak token rotation means a session token issued at login remains valid indefinitely or for an unreasonably long window. An attacker with a captured token from a morning session can still authenticate that evening. Strong implementations rotate tokens on significant actions and immediately invalidate the old one.
Missing cookie security attributes strip out the browser-level protections governing how tokens travel. Without the `HttpOnly` flag, JavaScript can read session cookies directly. Drop `Secure`, and cookies travel over unencrypted connections. Without a correctly scoped `SameSite` attribute, cross-origin requests carry session cookies they have no business carrying. These are single-line configuration settings, and they are frequently absent in production.
Browser isolation failures extend the risk to the endpoint itself. Session tokens stored in browser profiles are readable by any process that can access the profile directory. On endpoints without process isolation, malware running under user context can extract all stored session data with no application-layer interaction required.
Standard web application penetration testing validates authentication bypass, input handling, and access control. Most methodologies stop short of testing what happens after authentication completes, and that gap is exactly where session hijacking operates.
Session-focused penetration testing should cover token entropy (whether tokens are cryptographically random and sufficiently long), rotation behaviour after privilege changes, and complete session invalidation on logout across all active sessions. Testers should check cookie attribute configuration consistently across every environment, including staging and API endpoints where production-grade controls are frequently missing.
CORS policy testing belongs in scope. An application that permits cross-origin cookie transmission from an attacker-controlled domain has opened a session theft channel through its own configuration. Endpoint testing that checks browser credential store exposure completes the picture: an application with sound session management can still be compromised if the endpoint running it allows any user-context process to read the browser profile.
"We regularly test organisations that consider authentication a closed problem after deploying MFA. What they have not validated is what their application does with the session after login. That is where we consistently find the gap. Kevin Wotshela, Managing Director, Magix
POPIA Section 19 requires appropriate, reasonable technical measures to protect personal information. A web application issuing long-lived, poorly configured session tokens fails that standard. If that session is hijacked and customer data is accessed, Section 22 notification obligations apply, regardless of whether the application's authentication layer was technically bypassed.
PCI DSS Requirement 8 addresses session management directly for applications handling cardholder data. Requirement 6.2 mandates secure development and maintenance, which includes session token implementation and attribute configuration. For any South African business processing card payments, session security testing is a compliance control.
Ongoing vulnerability management supports this between point-in-time assessments, catching session security regressions introduced by deployment changes and configuration drift. Controls that pass in January may not survive an infrastructure update in March.
The post-authentication attack surface is real, documented, and exploited by attackers who have had years to refine these techniques. If your penetration testing scope does not explicitly cover session token handling, cookie attribute configuration, and browser credential store exposure, you cannot verify that your sessions are secure. Contact Magix to bring session security into your next web application assessment.
