App beveiliging: basis tot geavanceerd.

Waarom app-beveiliging belangrijk is

Een mobiele app is een aantrekkelijk doelwit. De binary draait op een apparaat waar u geen controle over hebt, communiceert over netwerken waar u geen controle over hebt, en bevat vaak credentials of tokens die directe toegang geven tot uw backend. Een succesvol misbruik kan tegelijkertijd een data-lek, een reputatieschade en een compliance-incident worden.

De vier laagjes van het aanvalsoppervlak

• Network — verkeer tussen app en server kan worden onderschept (man-in-the-middle), vooral op publieke wifi of via een malafide DNS-resolver.
• Device — het toestel zelf kan gerooteerd, gejailbreaked of besmet zijn met malware die meekijkt in het geheugen of het bestandssysteem van uw app.
• Server — de backend-API is in praktijk waar de meeste data-lekken vandaan komen. Een onveilig endpoint is dodelijker dan een ontbrekende certificate pin.
• Supply-chain — third-party SDK's, build-tools en CI/CD-systemen vormen een keten waarin elke schakel een aanvalsvector is.

Recente incidenten en wetgeving maken het belang nog scherper. De EU heeft sinds 2024 de DSA en de AI Act in werking, en de Cyber Resilience Act (CRA) wordt in 2027 volledig van toepassing op apps met digitale elementen. Dat betekent dat security niet langer een keuze is maar een ontwerpcriterium, ook voor relatief kleine apps in gereguleerde sectoren.

Niveau 1 — Basis (vereist voor elke app)

Dit zijn de eisen waar geen enkele productie-app aan voorbij mag. We zien ze keer op keer ontbreken bij MVP's die te snel naar de store gingen — en dat is bijna altijd een ramp die wachtte om te gebeuren.

HTTPS-only en transportbeveiliging

Alle netwerkverkeer moet over TLS. Op iOS regelt App Transport Security (ATS) dit standaard af; uitzonderingen op platte HTTP moeten expliciet in Info.plist en hebben een goede reden nodig. Op Android werkt de NetworkSecurityConfig hetzelfde idee uit: u declareert per domein welk verkeer is toegestaan. Geen losse HTTP-calls, geen "even voor debugging", geen cleartextTraffic enabled in productie.

Secure data storage

• iOS Keychain voor secrets, tokens, refresh-tokens, biometric-keys. Niet UserDefaults — die staat in een leesbaar plist-bestand.
• Android Keystore voor sleutels en credentials. Niet SharedPreferences — die is op gerooteerde devices triviaal uit te lezen.
• EncryptedSharedPreferences (AndroidX Security) als u ondanks alles iets in preferences moet zetten.
• Geen secrets in de binary — API-keys en client-secrets in de app-bundle zijn met een paar minuten te extraheren.

Authenticatie

Voor login gebruiken we standaard OAuth 2.0 en OpenID Connect (OIDC). Wachtwoorden worden server-side opgeslagen met een moderne password-hash (bcrypt, scrypt of Argon2 — geen SHA-256 of MD5). Sla wachtwoorden nooit in de app op; gebruik refresh-tokens via PKCE-flow voor mobile clients.

Input-validatie

Vertrouw nooit op input van de client. Alle validatie moet ook server-side gebeuren: de app valideert voor UX, de server valideert voor veiligheid. Dit voorkomt injectie-aanvallen, geforceerde state-changes en logica die alleen op het toestel zou bestaan.

Veilige update-flow en privacy-permissies

Een app moet zichzelf kunnen updaten zonder de gebruiker volledig opnieuw te laten configureren. Een goede in-app updateprompt (Android In-App Updates of een eigen versie-check tegen uw backend) zorgt dat oude, kwetsbare versies snel verdwijnen. Vraag bovendien alleen permissies aan die u daadwerkelijk gebruikt; te ruime permissies leiden zowel tot store-rejections als tot privacy-risico's.

Server-side eerst

Een belangrijk inzicht uit de OWASP-praktijk: de meeste mobile data-lekken komen van slecht beveiligde backends, niet van de app zelf. Een onbeveiligd endpoint dat alle gebruikersrecords teruggeeft is gevaarlijker dan een ontbrekende anti-debugging-check. Voor wie compliance-software laat ontwikkelen is onze ISO 27001-pagina een goed startpunt om te zien hoe wij die backend-laag aanvliegen.

Niveau 2 — Intermediate

Voor de meeste B2C-apps van enige omvang en alle apps met gebruikers-accounts hoort deze laag erbij. Het zijn maatregelen die de drempel voor aanvallers significant verhogen zonder dat ze de productontwikkeling lam leggen.

Token-management

Access-tokens hebben een korte levensduur (denk aan minuten), refresh-tokens een langere maar wel rotating implementatie. Een refresh-token moet bij elk gebruik vervangen worden; herbruik wijst op compromittering en moet de hele sessie invalideren. Server-side revocation moet altijd mogelijk zijn — gebruikers die hun toestel kwijtraken moeten kunnen uitloggen op afstand.

Biometric authentication

Face ID, Touch ID en Android Biometric maken her-authenticatie comfortabel zonder dat u wachtwoorden hoeft op te slaan. Belangrijk: de biometrische check ontgrendelt een Keystore-item; het wachtwoord zelf zit nooit in de app. De fallback (PIN, patroon) moet altijd via de OS-API verlopen.

Code-obfuscation en anti-debugging

• R8 op Android — Google's standaard-shrinker en obfuscator. Aanzetten in proguard-rules.pro. Voor commerciele apps onmisbaar.
• Swift en Objective-C — Apple's compiler doet beperkte symbol-stripping; voor sterkere bescherming bestaan tools als swiftshield.
• Anti-debugging — controleer of een debugger aan de app hangt en weiger gevoelige operaties wanneer dat zo is. Niet onfeilbaar, maar verhoogt wel de tijd die een aanvaller kwijt is.

UX-laag van security

• Secure-clipboard — wachtwoord-managers mogen credentials in het clipboard zetten, maar uw app mag dat niet zelf doen. Veeg gevoelige clipboards na een paar seconden leeg.
• Screenshot-protection — op Android via FLAG_SECURE op Activity-niveau, op iOS via een blur-overlay bij app-resign. Vooral relevant voor banking, zorg en HR-apps.
• MFA — bied tweede-factor aan via TOTP, WebAuthn of passkeys. Een SMS-OTP is beter dan niets, maar lang niet zo veilig als een hardware-gebonden factor.

Session-management

Sessies horen een server-side staat te hebben. Een uitgelogde gebruiker moet ook server-side ongeldig zijn, niet alleen client-side. Idle-timeouts, absolute-timeouts en device-binding zijn standaard onderdelen van een serieuze app.

Niveau 3 — Geavanceerd

Voor banking, fintech, zorg, defensie en alle apps waar een succesvolle aanval directe financiele of fysieke schade oplevert. Deze laag is niet goedkoop, maar voor de juiste use-case onmisbaar.

Certificate pinning

Standaard TLS vertrouwt alle door het OS goedgekeurde Certificate Authorities. Bij certificate pinning vertrouwt uw app alleen het CA-certificaat (of public key) van uw eigen backend. Een aanvaller die een geldig certificaat heeft uitgegeven gekregen kan dan nog steeds geen man-in-the-middle uitvoeren. Wel oppassen met sleutel-rotatie: een verlopen pin breekt uw app voor iedereen tegelijk. Gebruik altijd minstens twee pins (huidige en next-rotation) en een server-side noodupdate-kanaal.

Jailbreak- en root-detection

Detectie van gemodificeerde toestellen is omzeilbaar, maar verhoogt wel de drempel. Een aanvaller die uw app op zijn gerooteerde toestel wil debuggen heeft eerst werk te doen aan de detectie zelf. Voor financiele apps is een refused-launch op gerooteerde toestellen een redelijke default — voor B2B-apps op enterprise devices vaak een te zware ingreep.

Anti-tamper en runtime-integriteit

• Frida-detection — Frida is de meest gebruikte runtime-instrumentatie-tool voor mobile apps. Detecteer karakteristieke ports, libraries en stack-traces.
• Checksum-verificatie — bij opstart vergelijkt de app de checksum van zijn eigen binary met een verwachte waarde. Tampering breekt de check.
• Anti-hooking — voorkom dat method-swizzling of Java-hooks gevoelige methoden onderscheppen.

Hardware-backed key storage

• Secure Enclave (iOS) — een aparte coprocessor die sleutels nooit uit zichzelf laat lekken.
• StrongBox (Android) — een Trusted Execution Environment of dedicated security chip op moderne toestellen.
• TEE — generieke term voor hardware-isolatie die ARM TrustZone uitbreidt.

Device-attestation

App Attest (iOS) en Play Integrity (Android) laten uw backend verifieren dat een request van een echte, niet-gemodificeerde app op een echt toestel komt. Voor anti-fraud op betalingen, gokken, ticketing en accountregistratie inmiddels een de facto-standaard.

End-to-end encryption en zero-trust

Voor messaging-apps en gevoelige communicatie geldt end-to-end-encryptie als standaard, vaak gebaseerd op het Signal Protocol met double-ratchet sleutel-rotatie. Zero-trust gaat een stap verder: elke request wordt opnieuw geauthenticeerd, niet alleen bij login. Geen impliciet vertrouwen, geen tunnel-magie, geen "we zitten al binnen".

Penetration testing, SBOM en supply-chain

Voor serieuze apps hoort een jaarlijkse externe pen-test, of vaker bij major releases. Een Software Bill of Materials (SBOM) is sinds 2024 verplicht voor sommige sectoren en wordt onder de CRA breder. Supply-chain-security loopt via dependency-scanning, signed releases (Sigstore, Cosign) en strenge controle op build-pipelines. Wat dit concreet betekent voor compliance-software in zorg of fintech lichten we toe op onze NEN 7510-pagina en de GDPR-compliance-pagina.

Compliance-context

Beveiliging is niet alleen een technische maar ook een juridische opgave. De relevante kaders waar uw app rekening mee moet houden:

Het is verleidelijk om compliance als een afvinklijst te zien, maar in praktijk loopt het andersom: goede security-keuzes maken de compliance-paperwork makkelijker. Een audit op een goed beveiligde app is een formele bevestiging; een audit op een slecht beveiligde app is een gauntlet.

Tooling-landschap

Het ecosysteem voor mobile-security tooling is in de laatste vijf jaar volwassen geworden. Een ruwe inventarisatie van de categorieen die er toe doen:

Static Application Security Testing (SAST)

• SonarQube — open-core code-quality- en security-scanner met goede mobile-rule-sets.
• Snyk Code — SaaS, snel te integreren in CI/CD, met goede iOS/Android-coverage.
• Veracode — enterprise-keuze met diepe compliance-rapportage.

Software Composition Analysis (SCA)

• Snyk Open Source en Mend (voorheen WhiteSource) — dependency-scanning met geintegreerde fix-suggesties.
• GitHub Dependabot — gratis voor publieke en private repo's, doet automatische PR's voor patches.

Dynamic en mobile pen-test

• OWASP ZAP en Burp Suite — voor API-proxying en server-side pen-testing.
• MobSF — Mobile Security Framework, open-source, dekt zowel statische als dynamische analyse van iOS en Android.
• Frida en Objection — runtime-instrumentatie. Onmisbaar voor red-team-werk en even onmisbaar als doelwit van anti-tamper.
• drozer — Android-specifieke pen-test-framework.

Runtime-bescherming en bug-bounty

• Promon Shield, Verimatrix en Appdome — commerciele runtime application self-protection (RASP) suites voor apps in financiele en mediasectoren.
• HackerOne en Intigriti — bug-bounty-platforms. Voor een serieuze app na de eerste pen-test een natuurlijke vervolgstap.

Wanneer welk niveau?

Niet elke app heeft alle drie de niveaus nodig. Een grof beslissingskader:

• Standaard B2C-app (lifestyle, content, community) — Niveau 1 is verplicht, delen van Niveau 2 (token-management, MFA, screenshot-protection bij gevoelige views) is sterk aanbevolen.
• Banking en fintech — alle drie de niveaus, met certificate pinning, device-attestation en RASP als harde eisen. Plus PSD2-SCA.
• Zorg en medisch — alle drie de niveaus, met NEN 7510 of HIPAA als overlay. Voor medische devices ook MDR-eisen, met een eigen kwaliteitssysteem.
• B2B mid-market — Niveau 1 en 2 als baseline, met geselecteerde Niveau 3-onderdelen op basis van wat klanten in hun procurement-vragenlijst vragen. ISO 27001 is daar vaak de aanjager.

Veelgemaakte fouten

• Hardcoded API-keys in de binary — extractie kost een paar minuten met standaard reverse-engineering-tools. Server-side proxying of dynamische token-uitgifte is de juiste route.
• Geen certificate pinning bij high-value apps — voor banking, zorg en e-commerce is een MITM-aanval op publieke wifi een realistisch scenario. Wel pinning, en wel met sleutel-rotatie-strategie.
• Geen logging op authentication-failures — een brute-force-aanval op uw login-endpoint moet zichtbaar zijn in monitoring. Anders ontdekt u het pas als de schade al is aangericht.
• Te ruime permissies — een app die bij installatie locatie, contacten en SMS vraagt zonder zichtbare reden krijgt zowel een store-rejection als een vertrouwens-knauw bij gebruikers.
• Geen update-strategie — oude versies van uw app blijven in omloop met kwetsbaarheden waarvan u nog niet eens weet dat ze er zijn. Force-update-mechanismen en versie-deprecation zijn geen luxe.
• Geen CVD-beleid — zonder een Coordinated Vulnerability Disclosure-procedure weten beveiligers niet hoe ze u kunnen bereiken bij een vondst. Een eenvoudig security.txt en een werkende mailbox zijn de minimumeisen.

Voor wie aan de slag wil met een nieuwe app of een bestaande app wil laten doorlichten op deze punten, gaat onze app-ontwikkeling dienstpagina dieper in op hoe wij security in elke fase van een traject meenemen.

Veelgestelde vragen

Wat is de eerste laag van app-beveiliging die we moeten implementeren?

HTTPS-only verkeer en veilige opslag van secrets in Keychain of Keystore. Dat zijn twee maatregelen die in elk MVP horen, ongeacht het type app. Daarna komt de auth-laag (OAuth 2.0 / OIDC) en server-side input-validatie. Wie deze vier dingen op orde heeft, heeft de absolute basis te pakken.

Wat is de OWASP Mobile Top 10 en moeten wij ons daarop richten?

De OWASP Mobile Top 10 is een lijst van de meest voorkomende mobile-security-risico's, samengesteld door een internationale community van security-professionals. Voor elke serieuze app is het de gangbare baseline-checklist. We gebruiken de 2024-versie en mappen daaraan de MASVS-eisen voor diepgaande verificatie.

Wat is certificate pinning en heeft mijn app het echt nodig?

Bij certificate pinning vertrouwt uw app alleen het certificaat van uw eigen server, niet alle door het OS goedgekeurde CA's. Dit beschermt tegen man-in-the-middle-aanvallen via gecompromitteerde CA's. Voor banking, zorg en betaal-apps is het feitelijk standaard; voor een eenvoudige content-app is de extra onderhoudslast vaak niet de moeite waard. De keuze hangt af van de waarde van de data die over de verbinding gaat.

Is jailbreak- of root-detection zinvol als het toch te omzeilen is?

Ja, ondanks dat het omzeilbaar is. De drempel verhogen is een legitiem doel: een gemotiveerde aanvaller zal er doorheen komen, maar een opportunistische niet. Voor financiele apps is een refused-launch op gerooteerde toestellen verstandig; voor andere apps volstaat vaak een waarschuwing of een gedegradeerde feature-set.

Hoe vaak moeten we een penetration test doen?

Minimaal jaarlijks voor een serieuze productie-app, en daarnaast bij elke major release of significante architectuurwijziging. Een pen-test is geen eenmalig event maar een terugkerende controle. Bug-bounty-programma's vullen de tussenliggende periode in met permanente externe ogen op uw app.

Wat is het verschil tussen AVG en PCI-DSS voor onze app?

AVG (de Nederlandse uitwerking van de GDPR) gaat over persoonsgegevens van EU-burgers en geldt vrijwel altijd. PCI-DSS gaat specifiek over kaarttransactiedata en geldt alleen als u zelf creditcard-nummers verwerkt of opslaat. In praktijk gebruiken vrijwel alle apps tokenisatie via een payment-provider om buiten de PCI-DSS-scope te blijven; AVG-compliance is daarentegen onontkoombaar.

Wat bepaalt de kosten van een security-audit?

De scope (alleen mobile-binary of ook de backend?), de complexiteit van de architectuur, het verificatie-niveau dat u nastreeft (MASVS L1, L2 of R) en de mate van toegang die u de auditor geeft (black-box, grey-box, white-box). Een grey-box-audit op een middelgrote app vergt doorgaans een traject van meerdere sprints, met een rapport en een follow-up-ronde om bevindingen op te lossen.