Beveiligingsrisico's tussen applicaties

Micro Frontends bieden veel flexibiliteit doordat monolithische applicaties worden opgesplitst. Deze modulariteit brengt echter unieke beveiligingsuitdagingen met zich mee wanneer meerdere onafhankelijke applicaties samenwerken.

Voor het bouwen van veilige systemen is het cruciaal om te begrijpen hoe deze afzonderlijke onderdelen met elkaar samenwerken en welke risico's ontstaan door hun communicatie tussen applicaties en hun gedeelde omgeving.

De Same-Origin Policy (SOP) is een fundamenteel beveiligingsmechanisme van browsers. Het voorkomt dat webpagina's communiceren met bronnen van een andere origin (domein, protocol, poort).

Bij Micro Frontends kan SOP de modules als verschillende origins beschouwen, ook als ze allemaal hetzelfde hoofddomein hebben, wanneer ze zich op verschillende subdomeinen of poorten bevinden. Verkeerde configuraties kunnen hier leiden tot onbedoelde toegang tussen origins.

Cross-Site Scripting (XSS) ontstaat wanneer kwaadaardige scripts in vertrouwde websites worden geïnjecteerd. In een MFE-opzet kan een XSS-kwetsbaarheid in één externe applicatie bijzonder gevaarlijk zijn:

• Een gecompromitteerde externe module kan scripts in de hostapplicatie injecteren.
• Deze scripts kunnen vervolgens cookies en sessietokens stelen of de volledige gebruikersinterface verminken, waardoor alle gefedereerde modules worden getroffen.

Een goede opschoning van invoer en codering van uitvoer zijn in alle modules essentieel.

Een Content Security Policy (CSP) is een krachtige bescherming tegen XSS. Hiermee kun je opgeven welke bronnen van inhoud (scripts, stijlen, afbeeldingen) door de browser mogen worden geladen.

Voor MFE's moet de hostapplicatie een uitgebreide CSP definiëren die rekening houdt met alle legitieme script- en stijlbronnen van de externe modules. Dit beperkt de impact van een XSS-aanval doordat het uitvoeren van niet-geautoriseerde scripts wordt voorkomen.

Bij aanvallen met Cross-Site Request Forgery (CSRF) wordt de browser van een gebruiker ertoe misleid ongewenste acties uit te voeren in een webapplicatie waarbij de gebruiker is geauthenticeerd. Dit kan lastig zijn bij MFE's.

Als verschillende gefedereerde modules authenticatiecontexten delen, bijvoorbeeld cookies, kan een CSRF-aanval op één module mogelijk acties in een andere module beïnvloeden. De kritieke acties van elke MFE moeten worden beschermd met unieke CSRF-tokens met een korte geldigheidsduur.

Communicatie tussen Micro Frontends, rechtstreeks of via een gedeelde eventbus, moet veilig zijn. HTTPS gebruiken is verplicht voor al het netwerkverkeer tussen modules en de host.

Als MFE's communiceren via aangepaste gebeurtenissen of gedeelde globale objecten, moet je ervoor zorgen dat gevoelige gegevens niet rechtstreeks worden doorgegeven of door de ontvangende module goed worden opgeschoond en gevalideerd. Behandel alle binnenkomende gegevens, zelfs van andere MFE's, als mogelijk niet-vertrouwd.

Een van de onopvallende risico's bij MFE's is onbedoeld lekken van gegevens of ongeautoriseerde toegang tussen modules. Dit kan gebeuren wanneer:

• De globale status wordt gedeeld zonder goed toegangsbeheer.
• Een externe module ruimere machtigingen heeft dan nodig.
• Gevoelige gegevens beschikbaar worden gesteld via openbare API's die niet goed zijn beveiligd.

Implementeer strikte gegevenscontracten en zorg ervoor dat modules alleen gegevens benaderen die relevant zijn voor hun functie.

Micro Frontends zijn vaak sterk afhankelijk van gedeelde bibliotheken en afhankelijkheden van derden. Een kwetsbaarheid in een algemene hulpprogrammabibliotheek of een gecompromitteerde buildtool kan je volledige gefedereerde ecosysteem treffen.

Dit staat bekend als een aanval op de toeleveringsketen. Scan afhankelijkheden regelmatig op bekende kwetsbaarheden, controleer bronnen van derden zorgvuldig en houd strikte controle over je build- en implementatiepijplijnen voor alle gefedereerde applicaties.

Overweeg voor zeer gevoelige of mogelijk niet-vertrouwde externe applicaties van derden sterkere isolatietechnieken:

• Iframes: Kunnen een sterke beveiligingsgrens bieden en scripts en stijlen isoleren, maar brengen integratie-uitdagingen met zich mee.
• Web Workers: Voeren berekeningen uit in een afzonderlijke thread, waardoor directe DOM-toegang wordt voorkomen en mogelijke schade door kwaadaardige scripts wordt beperkt.

Kies de isolatie op basis van het vertrouwensniveau en de integratiebehoeften van de externe module.

In deze les hebben we veelvoorkomende beveiligingsrisico's tussen applicaties in Micro Frontends onderzocht, waaronder verspreiding van XSS, CSRF, onveilige communicatie, het lekken van gegevens en kwetsbaarheden in de toeleveringsketen.

Gebruik een gelaagde verdediging: sterke CSP's, grondige opschoning van invoer, veilige communicatie (HTTPS) en zorgvuldig toegangsbeheer zijn essentieel voor het bouwen van veerkrachtige en veilige gefedereerde applicaties.