Diefstal van gegevens, malware, gehackte API's... het gebruik van mobiele applicaties neemt explosief toe, en dat geldt ook voor het aantal aanvallen. Zijn uw mobiele applicaties echt veilig? Hoe kunt u, afgezien van eenvoudige versleuteling, echte veiligheid garanderen zonder de gebruikerservaring te belemmeren? Hoe gaat u om met veilige opslag of verharding client/server? En uw tests? Zijn ze afgestemd op de huidige normen? Ontdek de essentiële praktijken en tools om veilige, performante apps te coderen... die echt vertrouwen wekken.
Laten we eerst eens kijken naar enkele cijfers. In 2024 registreerde Akamai maar liefst 311 miljard aanvallen. Het meest opvallende? Bijna de helft daarvan richt zich rechtstreeks op API's die als achterdeurtjes dienen. Dat is de eerste grote uitdaging voor ontwikkelaars.
Maar dit zijn lang niet de enige aanvallen op mobiele telefoons! In 2025 neemt de druk toe. Het aantal aanvallen op Android-smartphones is sterk gestegen. van 29 % in de eerste helft van 2025 ten opzichte van het voorgaande jaar, volgens Kaspersky.
Cybercriminelen hoeven niet ver te zoeken: ze richten zich op wat direct geld oplevert. OTP's (eenmalige wachtwoorden) om tweefactorauthenticatie te omzeilen, wallets om digitale tegoeden weg te sluizen en natuurlijk bankgegevens, die voor hen nog steeds het heilige graal zijn.
Android is het favoriete doelwit, maar iOS is niet langer het onschendbare toevluchtsoord dat we ons enkele jaren geleden nog voorstelden.
De veiligheid van mobiele apps wordt dus een prioriteit.
De dreiging in cijfers: de explosieve toename van het aanvalsoppervlak
| Doelwit van de aanval | Statistieken (2025) | Impact voor de ontwikkelaar |
|---|---|---|
| Applicatieaanvallen | 83 % organisaties die in januari werden aangevallen 2025 (65 % op 2024) (Digital.ai) | Prioriteer continue tests, klantharding |
| API-aanvallen | > 40.000 incidenten bij S1 2025 (Thales) | Controleer elk eindpunt + misbruikpreventie (detectie/blokkering van misbruik, bots, fraude) |
| AI/API-kwetsbaarheden | + 1025 % van AI-CVE in 2024 waarvan 98,9 % gerelateerd aan API's (Wallarm) | Test inputs/outputs en AAA-controles |
| Android-bedreigingen |
+ 29 % aanvallen S1 2025 vs S1 2024 (Kaspersky) |
Leg op anti-tamper (wijzigingen aan de app voorkomen) en omgevingsdetectie |
| Gemiddelde kosten van een inbreuk | 4,88 M$ (IBM) | De inertie kost duurder dan gereedschap |
Uw stappenplan: 3 pijlers voor mobiele beveiliging
Geconfronteerd met deze vloedgolf volstaan checklists die in een hoekje van een tafel zijn gekrabbeld niet meer. U hebt een solide verdedigingsarchitectuur nodig, gebaseerd op drie complementaire pijlers die elkaar versterken.
1er pijler: het referentiekader dat uw aanpak structureert
Voordat u ook maar één regel code schrijft, heeft u referentiepunten nodig. Dat is precies wat u krijgt met De OWASP Mobile Top 10 in de versie van 2024.
Dit referentiekader identificeert de tien grootste risico's voor uw mobiele applicaties, van onbeveiligde opslag tot zwakke cryptografie en code-injecties. Elk risico wordt gedocumenteerd, uitgelegd en in context geplaatst. En de OWASP Mobile Top 10 biedt u oplossingen voor elk probleem.
Bovendien dient dit referentiekader als basis voor discussies met elk beveiligingsteam.
Maar een opsomming van gevaren volstaat niet. Deze abstracte bedreigingen moeten worden omgezet in concrete acties, en daar komt het MASVS v2 (Standaard voor de verificatie van de veiligheid van mobiele applicaties).
Deze norm fungeert als universele vertaler tussen de wereld van risico's en die van ontwikkelaars.
Laten we een concreet voorbeeld nemen: het risico van «onbeveiligde gegevensopslag» wordt in het MASVS een precieze en controleerbare vereiste: «de applicatie mag geen geheimen in leesbare vorm opslaan in de voorkeuren». Gedaan met artistieke vaagheid, plaats voor duidelijk omschreven criteria.
Volg de MASTG-gids
Om te controleren of u aan deze vereisten voldoet, kunt u vervolgens gebruikmaken van de MASTG, de Mobile Application Security Testing Guide, die u praktische en reproduceerbare testscenario's biedt.
Deze trilogie OWASP-MASVS-MASTG vormt de ruggengraat van uw kwaliteitsgarantie op het gebied van veiligheid.
Hélène, Engineering Manager in een B2B-organisatie, vertelt hoe haar team het MASVS heeft omgezet in een productbacklog:
«Toen we besloten om de MASVS Echt, we zijn gestopt met grote uitspraken en zijn overgegaan op concrete verschillen. We hadden 17 rode vlekken op het deel VEERKRACHT : anti-debug, anti-hook, loglekken... We hebben een enkelvoudig bord verdeeld over devs, QA en beveiliging, en twee speciale sprints gepland. Voor elke user story een MASTG-testbewijs was vereist. Resultaat: binnen drie weken geen gemakkelijke bypasses meer en een team uitgelijnd op basis van hetzelfde interpretatiekader. Vandaag de dag is er geen discussie meer: als het ernstig is, dan maatregel. »
2ᵉ pijler: actieve verdediging aan de kant van de klant
Uw applicatie draait op een apparaat waarover u geen controle hebt. Dat is een feit. De gebruiker kan geroot zijn Android, gejailbreakt zijn iPhone, of erger nog, malware geïnstalleerd die alles afluistert wat er wordt verzonden. De fundamentele vraag wordt dan: hoe weet u of u echt met UW applicatie communiceert en dat het apparaat veilig is?
Het antwoord ligt in de’materieel bewijs, dit vermogen om uw applicatie koppelen aan de Hardware Security Module (HSM) van het apparaat.
Op Android, dit betekent dat er onmiddellijk moet worden overgestapt op Play Integrity (dat SafetyNet heeft vervangen). Play Integrity controleert niet alleen de integriteit van het binaire bestand, maar bevestigt ook de werkelijke status van de omgeving: aanwezigheid van wortel, detectie van malware, tekenen van vervalsing. Uw code moet meedogenloos zijn: blokkeer elke uitvoering als de status MEETS_BASIC_INTEGRITY mislukt. Geen halve maatregelen, geen verslechterde modus die een vastberaden aanvaller zou laten passeren.
Op iOS, de reflex heet App Attest. Deze door Apple aangeboden dienst koppelt uw applicatie cryptografisch aan uw server. Concreet gezegd levert deze dienst een token dat uw back-end bij elke gevoelige oproep moet valideren. Zo wordt bewezen dat het inderdaad UW legitieme applicatie is die het verzoek verstuurt, en niet een gewijzigde versie of een kwaadaardige kloon.
Bewaar geheimen veilig
Wat betreft de geheimen van de applicatie, deze mogen nooit buiten hun fysieke kluis komen., Android-sleutelbewaarplaats en iOS-sleutelhanger. Ze beperken zich niet tot het versleutelen van uw sleutels en tokens, verbinden ze deze met de hardware van het apparaat. Deze verbinding maakt extractie vrijwel onmogelijk zonder ingrijpende fysieke ingrepen, wat de situatie voor de aanvaller volledig verandert. Sla dus nooit, maar dan ook nooit, een geheim in leesbare vorm op in uw binaire bestanden of gedeelde voorkeuren.
Maëlys, Android-lead in een applicatie detailhandel, getuigt van de onmiddellijke impact van deze maatregelen:
«We hadden vermoedens over app-klonen die onze gevoelige eindpunten aanriepen. De dag waarop we App Attest iOS-kant en Play Integrity Aan de Android-kant hebben we de spelregels veranderd. De achterkant weigert voortaan elke kritische oproep zonder geldig attest, punt. In twee sprints zijn de pogingen tot fraude die zichtbaar waren in onze logboeken gedeeld door drie. Voor de gebruiker is er niets veranderd: geen extra wrijving, alleen een radiostilte scripts die onze API's “bruteforceten”.
3e pijler: de gepantserde API
De API is de plek waar mobiele veiligheid wordt gewonnen of verloren. Een gestolen toegangstoken is letterlijk de sleutel tot het koninkrijk, volledige toegang tot het account van de gebruiker en al zijn gegevens.
Als u nog steeds de impliciete OAuth 2.0-stream gebruikt, speelt u de aanvaller in de kaart. Door over te stappen op OAuth 2.1 met PKCE verplicht is geen simpele cosmetische update, maar het dichten van een gapend gat. Aangezien de OAuth 2.1-specificatie nog steeds een internetontwerp is, is het essentieel om deze maatregelen nu meteen toe te passen.
PKCE (Proof Key for Code Exchange) garandeert dat zelfs als een aanvaller de autorisatiecode tijdens de omleiding onderschept, hij deze niet kan inwisselen voor een toegangstoken.
Dat is al een eerste solide vergrendeling, maar het lost slechts een deel van het probleem op.
Wat gebeurt er als het definitieve toegangstoken achteraf wordt gestolen? Via malware, een lek in de logboeken, een XSS? Dat is waar DPoP (Demonstration of Proof-of-Possession) komt in beeld. Dit gestandaardiseerde mechanisme, dat eenvoudiger te implementeren is dan mTLS op mobiele apparaten, verandert de situatie fundamenteel.
Concreet betekent dit met DPoP:
- De mobiele client genereert een lokaal sleutelpaar.
- Hij tekent elk verzoek API met zijn privésleutel (via een speciale DPoP-header).
- De server valideert de handtekening en controleert of het toegangstoken inderdaad aan deze openbare sleutel is gekoppeld.
Resultaat: een gestolen toegangstoken wordt onbruikbaar. De aanvaller die niet over de privésleutel voor ondertekening beschikt, blijft achter met een eenvoudige tekenreeks zonder enige bruikbare waarde. Het is elegant, efficiënt en sluit een deur die veel applicaties wijd open laten staan.
Tot slot: vergeet nooit de transportlaag. Eis minimaal TLS 1.2 en geef de voorkeur aan TLS 1.3, verbannen, verbannen zwakke versleutelingssuites (volgens de aanbevelingen van ANSSI of Mozilla). Gebruik HSTS (HTTP Strict Transport Security) voor uw voorkant alleen op het web om aanvallen via onbeveiligde verbindingen te voorkomen. Voor native apps geeft u de voorkeur aan certificaatpinning (Android Network Security Config, iOS ATS) en een geplande rotatie van sleutels. Deze maatregelen zijn volledig onzichtbaar voor de eindgebruiker... en sluiten opportunistische aanvallers volledig buiten.
Clara, SRE bij een HR-SaaS-bedrijf, vat de impact goed samen:
«We hebben genormaliseerd TLS 1.3/HSTS over het hele park. Voor de klanten is er niets veranderd. Voor ons is er een hoop’geluidswaarschuwingen verdwenen en de externe scans zijn eindelijk schoon. Eerlijk gezegd is dit een van de weinige maatregelen bijna kosteloos en grote impact die snel kan worden ingezet.»
De twee blinde vlekken die alles kunnen veranderen
Naast deze drie pijlers zijn er vaak nog twee blinde vlekken in mobiele beveiligingsstrategieën. Dit zijn dode hoeken die, als ze worden genegeerd, al uw inspanningen teniet kunnen doen.
De eerste blinde vlek: uw supply chain, een onzichtbaar mijnenveld
Laten we eerlijk zijn: die analytics-SDK die u twee jaar geleden hebt geïntegreerd, die advertentiemodule die u zo handig leek, kunnen van de ene op de andere dag veranderen in een Trojaans paard. Een kwetsbaarheid die wordt ontdekt in een afhankelijkheid van een derde partij, een SDK die wordt overgenomen door een bedrijf dat minder streng is op het gebied van beveiliging, en uw hele applicatie wordt kwetsbaar.
De eerste stap is om precies te weten wat u meeneemt. Hiervoor moet u, genereer systematisch een SBOM, een Software Bill of Materials, in CycloneDX-formaat bij elke build.
Deze volledige inventarisatie geeft een overzicht van al uw directe en transitieve afhankelijkheden, waardoor een nauwkeurige kaart van uw aanvalsoppervlak wordt gecreëerd.
Maar een inventarisatie alleen is niet voldoende, deze moet ook worden geanalyseerd. Daar komen de SCA-tools (Software Composition Analysis) om de hoek kijken, die uw SBOM scannen om bekende kwetsbaarheden op te sporen. En bovenal: stel elke afhankelijkheid in vraag: heeft deze advertentie-SDK echt toegang nodig tot het netwerk EN de contacten van de gebruiker? Documenteer deze keuzes en schrap meedogenloos alle overbodige toegangen.
Louis, AppSec-manager bij een mediabedrijf, ontdekte een onverwacht voordeel van deze aanpak:
«Toen we onze eerste eigen SBOM CycloneDX uitbrachten, dachten we dat we gerust konden zijn. De SCA-scan bracht echter een SDK-advertentie aan het licht met bizarre machtigingen en een nieuwe CVE. We hebben de SDK verwijderd, een goedkeuringsproces voor afhankelijkheden ingevoerd en een beoordeling van de scopes aan elke release toegevoegd. Onverwacht voordeel: het netwerkverbruik is gedaald, evenals de opstarttijd. De winst op het gebied van prestaties en veiligheid hadden we niet verwacht.»
De tweede blinde vlek: het ontbreken van DevSecOps, of hoe je problemen voor je uitschuift
De veiligheid wordt aan het einde van de cyclus getest, wat garandeert dat kritieke problemen worden ontdekt wanneer het te laat is om ze nog correct te verhelpen. Veiligheid moet dus een voorwaarde worden voor het bouwen van software.
Automatiseer hiervoor uw beveiligingscyclus. Start de statische analyse (SAST) en de afhankelijkheidsanalyse (SCA) op elke commit. Integreer tools zoals Semgrep of SonarQube voor de code, Syft (SBOM-generatie) en Grype (kwetsbaarheidsscan). Het doel? Breken bouwen als een geheim is hardgecodeerd of als er een kritieke kwetsbaarheid wordt gevonden. Geen tolerantie, geen «we zien wel later».
Ga vervolgens naar het binaire bestand zelf. Integreer MobSF, het Mobile Security Framework, in uw CI-pijplijn om de gegenereerde APK of IPA te controleren. Als de basisconfiguraties van MASVS niet worden nageleefd, zal de bouwen mislukt.
Voeg API-tests toe : DPoP-controles (nonce/jti/iat/htu/htm), detectie van misbruik/bots en rotatie van refresh tokens met detectie van hergebruik.
Maak ten slotte gebruik van uw veiligheidstests. Gebruik Frida of Bezwaar om de controles van’anti-sabotage. Als uw afweer tegen root/jailbreak of de SSL-pinning niet reageren zoals verwacht, de bouwen mislukt. Deze strengheid kan in het begin hard overkomen, maar het verandert de kwaliteit van wat je aflevert drastisch.
Romain, DevSecOps bij een EdTech-bedrijf, getuigt van de culturele verandering:
«De eerste keer dat we de build voor een MobSF-regressie hebben gebroken, was dat niet populair. Twee dagen later had niemand het er meer over: de quick wins op het gebied van beveiliging kwamen vóór de productie uit, niet erna. We hebben een wekelijks controleverslag toegevoegd, dat een criterium voor productacceptatie is geworden. Als bonus is de stress bij MEP verdwenen: we weten wat we leveren.»
Uw actieplan: waar te beginnen?
Geconfronteerd met deze lijst van maatregelen dreigt verlamming. Waar moet je beginnen? Hoe stel je prioriteiten? Hier volgt een pragmatisch stappenplan, opgedeeld in drie fasen van elk twee weken.
Week 1-2: breng de bestaande situatie in kaart
- Laat uw app door de MASVS v2
- Identificeer uw 5 kritieke afwijkingen (die uw gebruikers het meest blootstellen)
- Maak uw eerste SBOM CycloneDX met Syft en scan het met Grype
Week 3-4: leg de basis
- Klant : Play Integrity (Android) + App Attest (iOS)
- API : PKCE + DPoP op uw eindpunten gevoelige (die kritieke gegevens of financiële transacties verwerken)
- Vervoer : minimaal TLS 1.2/bij voorkeur 1.3 + certificate pinning (Android Network Security Config / iOS ATS) (HSTS voorbehouden aan uw webfrontends)
Week 5-6: industrialiseer in de CI/CD-pijplijn
- Integreer SAST/SCA met de regel: elke kritieke kwetsbaarheid breekt de build
- Toevoegen MobSF voor de controle van uw binaire bestanden
- Een test automatiseren Frida over uw belangrijkste tegenmaatregelen + DPoP API-tests
De open bar is gesloten... voorgoed!
Het tijdperk waarin mobiele apparaten als «gewone klanten» werden beschouwd, is voorbij. Ze zijn nu een eindpunt kritiek. De cijfers van 2025 bewijzen het ondubbelzinnig: de aanvallers hebben er de tijd van hun leven.
Fysieke certificering, versterkte authenticatie en een meedogenloze identiteitskaart zijn niet langer voorbehouden aan banktoepassingen.
Beveiliging is niet langer een functie die je toevoegt als het budget het toelaat. Het is de basis van het vertrouwen dat je opbouwt bij je gebruikers. Wacht niet op een rampzalig auditrapport of een datalek dat je miljoenen kost. Je nieuwe mantra moet zijn: « Als het niet veilig is, gaat het niet in productie. »
Het is niet langer uw taak om alleen maar werkende code te leveren. Het is uw taak om vertrouwen te wekken. Uw volgende commit zal uw eerste verdedigingslinie zijn. Zorg ervoor dat het telt.
