Säkerhetschecklista för mobilappar
Av CodexierPublicerad 5 min läsning
En mobilapp kör på hårdvara ni inte äger, i nätverk ni inte litar på, bredvid appar ni inte valt. Det ändrar vad säkerhet betyder jämfört med en webbplats: enheten kan tappas bort, appen kan dekompileras och nätverket kan vara ett kafé. Den här checklistan följer strukturen i OWASP:s riktlinjer för mobil och fokuserar på vad en företagsapp för personal eller kunder faktiskt behöver, inte på vad en bankapp behöver.
Säker lagring på enheten
- Sessionstoken i iOS Keychain eller Android Keystore, med kort livslängd och ett förnyelseflöde, aldrig i en vanlig fil eller appens inställningar.
- Cachad verksamhetsdata krypterad i vila om den är personlig eller affärskritisk, och raderad vid utloggning och efter en tid offline.
- Inga känsliga uppgifter i loggar, kraschrapporter eller skärmbilder. Maskera appen i appväxlaren på skärmar som visar personuppgifter.
- Fjärradering eller tvingad ny inloggning när en enhet anmäls borttappad; servern ogiltigförklarar sessionen, inte appen.
Säker överföring
All trafik går över HTTPS med aktuella TLS-versioner, och appen vägrar falla tillbaka. Båda plattformarna kräver det som standard numera; risken är en utvecklare som stänger av det för att testa mot en lokal server och levererar det så.
- Inga undantag för okrypterad trafik i releasekonfigurationen. Kontrollera Androids nätverkssäkerhetskonfiguration och iOS transportinställningar före varje release.
- Certifikatfästning bara för appar med högt skyddsvärde och bara med en rotationsplan; ett fäst certifikat som går ut låser appen för varje användare.
- Tredjeparts-SDK:er (analys, kraschrapportering, annonser) skickar också data. Lista dem, läs vad de samlar in och ta bort dem ni inte kan motivera för en kund.
Hemligheter och konfiguration
Utgå från att binären är offentlig
Vem som helst kan ladda ned och dekompilera appen. En API-nyckel i den är en publicerad nyckel. Hemligheter mellan servrar skickas aldrig med i appen.
Avgränsa det som måste ligga på klienten
Kartnycklar, analysnycklar och liknande begränsas per plattform och paket-id, roteras vid läcka och övervakas för ovanlig användning.
Separata miljöer
Utveckling, test och produktion har olika API-adresser och nycklar. Ett testbygge får inte kunna nå produktionsdata.
Tester och uppdatering av beroenden
Mobilappar förfaller snabbare än webbplatser: operativsystemen ändras årligen, bibliotek publicerar säkerhetsfixar månadsvis, och en app som inte byggs om slutar fungera eller slutar vara säker. Säkerhet är en rutin, inte en lanseringsuppgift.
- Automatisk skanning av beroenden i byggkedjan, med ett månatligt uppdateringsfönster och ett ombygge även när inget annat ändrats.
- Ett kort säkerhetstest vid varje release: tvåkontotestet av behörigheter, en kontroll av releasekonfigurationen, en titt på vad appen lagrar på en enhet.
- En årlig extern granskning för appar som hanterar personuppgifter eller pengar, avgränsad till API och lagring, inte ett fullt penetrationstest om inte en kund kräver det.
- Krasch- och felövervakning med personuppgifter bortrensade, så att ett fel syns innan en användare rapporterar det.
Det här är rutinen vår tjänst för appunderhåll och skalning kör varje månad för appar vi inte nödvändigtvis byggt. Vill ni ha en engångskontroll först täcker en hälsogranskning samma lista en gång; båda är fasta priser på prissidan.
När det här är mer än ni behöver
En intern app som visar ett schema och inte lagrar något personligt behöver punkterna om inloggning, överföring och uppdateringar och lite mer. En kundapp som hanterar betalningar, hälsodata eller identitet behöver allt plus plattformarnas egna krav för de kategorierna, och förmodligen BankID. Byggdes er app av en byrå som inte längre svarar är första steget inte den här listan utan att få källkod och butikskonton i egna händer, vilket ett kort samtal kan hjälpa er planera.
Vanliga frågor
Är en plattformsoberoende app mindre säker än en native-app?
Nej. Appar i React Native, Flutter och Capacitor använder samma nyckellager, samma TLS-stack och samma butiksgranskning. En apps säkerhet avgörs av hur API och lagring hanteras, inte av ramverket. Dåligt skrivna native-appar är lika vanliga som dåligt skrivna plattformsoberoende.
Behöver vi biometrisk inloggning?
För en kundapp som förblir inloggad är biometrisk upplåsning via plattformens API ett billigt skydd mot en borttappad mobil, och användarna förväntar sig det. För en personalapp på delade enheter kan en PIN-kod med kort tidsgräns passa bättre. Oavsett är det serversessionen, inte biometrin, som återkallas.
Vad kontrollerar Apple och Google i granskningen?
Granskningen kontrollerar integritetsdeklarationer, behörigheter, användning av plattformens API:er och policyefterlevnad. Den testar inte er API-behörighet eller er lagringshantering. Godkänd granskning betyder att appen följer butikens regler, inte att den är säker.
Osäker på vilka punkter er app redan klarar?
Ta med appen och en beskrivning av vad den lagrar till ett kort samtal. Vi säger vilka kontroller som brådskar, vilka som kan vänta och vad en månatlig underhållsrutin som täcker dem skulle kosta.
Boka ett kostnadsfritt 15-minuterssamtal