TSU-04: Insecure published integrations
TSU-04 richt zich op onveilig ingerichte of geïmplementeerde Published Integrations. Zorg dat authenticatie, autorisatie en validatie consequent zijn toegepast en dat alleen vertrouwde systemen toegang hebben. Zo voorkom je dat API-integraties het zwakke punt van je Mendix-app worden.
Published integrations: een belangrijk schakelelement en doelwit
Published Integrations maken het mogelijk om microflows en entiteiten beschikbaar te stellen aan externe systemen via standaard API-protocollen zoals SOAP, REST of OData. Ze vormen dus de schakel tussen jouw applicatie en andere systemen.
In de praktijk worden ze gebruikt om:- gegevens te delen met interne applicaties,
- data-uitwisseling mogelijk te maken met (semi)vertrouwde derde partijen,
- of inlog- en sessiegegevens te koppelen binnen Single Sign-On-oplossingen.
Omdat deze integraties vaak met vertrouwde systemen communiceren, verwerken ze regelmatig gevoelige data en gebruiken ze soms eigen authenticatie- en autorisatiemethoden. Wanneer een integratie verkeerd is ingericht of geïmplementeerd, kan dit leiden tot ongeautoriseerde toegang tot gegevens of functies, of tot het omzeilen van beveiligingslimieten voor externe partijen.
Beperk risico’s door microflows slim en veilig in te richten
Om TSU-04-kwetsbaarheden te voorkomen, richt je Published Integrations zo in dat alleen geautoriseerde systemen toegang krijgen.
Beperk rechten op twee niveaus:
- het integratieniveau (toegestane rollen)
- de microflows of entiteiten die via de integratie worden gepubliceerd.
Volg deze best practices
- Gebruik geen ‘no authentication’-optie, tenzij alle bewerkingen volledig openbaar zijn.
- Geef integratietoegang nooit aan module roles die ook aan gewone gebruikers zijn gekoppeld. Gebruik aparte integration-accounts met eigen module roles.
- Vermijd zelfgemaakte authenticatie. Gebruik liever de standaard Mendix-authenticatie met sterke, willekeurig gegenereerde wachtwoorden.
- Als maatwerk nodig is, kies dan een geteste en onderhouden Marketplace-module in plaats van eigen code.
- Gebruik bij maatwerk de optie “custom authentication” in plaats van ‘no authentication’ met losse checks per operatie. Zo blijft authenticatie uniform en consistent.
- Als een integratie meerdere ‘allowed roles’ bevat (bijvoorbeeld voor partners met verschillende vertrouwensniveaus), geef dan per microflow alleen toegang aan de rol die het echt nodig heeft. Vermijd dat alle rollen overal worden herhaald.
- Gebruik bij Import Mappings geen directe koppeling van gebruikersinvoer aan persistente entiteiten. Dit kan leiden tot datalekken of datamanipulatie. Map eerst naar non-persistent entiteiten, valideer de relevante attributen en voer daarna pas updates of creaties uit.
Kwetsbaarheden binnen TSU-04
- Ontbrekende authenticatie bij gevoelige integratie: externe partijen krijgen directe toegang tot vertrouwelijke gegevens.
- Gebruikerstoegang tot integratie-endpoints: gewone gebruikers kunnen API’s aanroepen die alleen voor systemen bedoeld zijn.
- Onjuiste module role gekoppeld aan operation-microflow: leidt tot te ruime rechten.
- Onveilige maatwerk-authenticatie: zelfgeschreven authenticatieprocessen missen vaak robuuste validatie of logging.
- Datamanipulatie via import mapping: invoer wordt zonder controle direct opgeslagen of gewijzigd.
- Direct object reference in import mapping: gebruikers kunnen object-ID’s manipuleren en ongeoorloofde data benaderen.