1. Inledning
När tillgänglighet blir en risk
Låt oss börja med att definiera vad vi menar med en applikation och varför den har en så central funktion i dagens verksamheter.
För många organisationer är applikationerna en mycket stor del av själva verksamheten. Det är där kunder möter er, där affärsprocesser genomförs och där data skapas, bearbetas och delas. I många fall är det också där intäkterna genereras.
Samtidigt har applikationer blivit mer exponerade än någonsin tidigare. De ska nås via webben, via mobiltelefoner och surfplattor och ibland även direkt från andra system. De är byggda för att vara tillgängliga och kommunikationen kan ske på flera olika sätt.
När vi i denna guide pratar om applikationer menar vi därför inte bara ett program som installeras på en dator eller en mobil. Vi menar hela systemet bakom och det gränssnitt där verksamhetens data och funktioner möter användare och andra system. Applikationen är alltså både logiken och ytan där information behandlas och görs tillgänglig.
I dag är applikationen ofta det primära gränssnittet mot användaren. För inte så många år sedan behövde vi ringa ett samtal eller besöka ett kontor för att köpa något, flytta pengar eller öppna ett konto. I dag gör vi det själva, direkt i en applikation. Det är snabbare, effektivare och helt i linje med hur vi vill konsumera tjänster.
Det innebär att verksamhetens mest värdefulla tillgångar i praktiken exponeras genom applikationerna.
Så hur skyddar vi dessa så att information inte hamnar på fel plats eller delas på fel sätt?
Alternativa versioner av guiden
Guiden går även att ladda ner som PDF för dig som vill kunna läsa den offline.
Och för dig som inte vill eller har möjlighet att läsa, så har vi med hjälp av AI tagit fram ljud- och video-sammanfattningar av guiden.
Samtliga ljud-podar finns även på Cuebids Spotify-konto och alla videos hittar du även på Cuebids YouTube.
2. Är applikationssäkerhet verkligen ett eget område?
Applikationer är byggda för att vara tillgängliga.
Det är deras uppdrag.
De ska ta emot förfrågningar, behandla information, exponera funktioner via webbgränssnitt, mobilappar och öppna API:er som utvecklare kan använda för att skapa nya kopplingar och gränssnitt, allt för att leverera tjänster till kunder, partners och interna användare. För att kunna göra det måste de släppas igenom brandväggar och traditionella säkerhetslösningar – lösningar som i första hand är konstruerade för att skydda nätverk och infrastruktur.
Det innebär att applikationer verkar under en annan logik än klassisk IT-säkerhet.
- En brandvägg analyserar IP-adresser, portar och trafikflöden. Den avgör om trafik ska tillåtas eller blockeras baserat på tekniska parametrar.
- Applikationen däremot arbetar med affärslogik, användarroller, dataobjekt och API-anrop. Den hanterar relationer, processer och beslut som är direkt kopplade till verksamhetens värdeskapande.
Det är två helt olika perspektiv.
Och det är i det glappet som behovet av applikationssäkerhet uppstår.
Samtidigt visar dagens hotbild att många angrepp initialt börjar någon annanstans – via phishing, stulna identiteter, komprometterade fjärranslutningar eller kända sårbarheter i infrastrukturen. Det börjar även bli allt mer vanligt med så kallade “Supply chain” angrepp, där man tar sig in via betrodda partners och tjänster. Allt detta innebär att angriparen ofta redan befinner sig innanför nätverksgränsen när den verkliga påverkan börjar.
Och här blir applikationssäkerhet helt avgörande. Både för att skydda era applikationer mot angrepp och för att förhindra att de används som en del av ett supply chain-angrepp mot någon annan.
När en angripare väl har tagit sig in i miljön är det applikationen som innehåller kundernas data, verksamhetens immateriella värden, den affärslogik som styr processerna och de API:er som driver digitala tjänster. Det är här information kan hämtas ut i stor skala, behörigheter kan missbrukas och funktioner kan manipuleras utan att trafiken i sig ser misstänkt ut ur ett nätverksperspektiv.
Om skyddet stannar vid nätverksgränsen och/eller i infrastrukturen finns det inget som förstår vad som är ett legitimt affärsbeteende och vad som är ett missbruk av funktioner.
Eller så här…
Tänk dig att du driver en bank. Byggnaden har säkerhetsdörrar, kameror och väktare. Ingen obehörig kan ta sig in i valvet, där pengarna finns. Säkerheten och övervakningen runt byggnaden fungerar.
Men banken är ju till för kunderna, som behöver tillgång till sina pengar. Och när kunden har passerat väktaren vid dörren och identifierat sig, så är personalens jobb att hjälpa kunden hantera sina pengar som finns i banken. Det gör man genom att ta emot instruktioner, genomföra transaktioner och svara på frågor. Personalen är framför allt tränad i service och de specifika arbetsuppgifterna, inte i att misstänka varje enskild kund.
Applikationer fungerar på samma sätt. De är designade för att ta emot input, filer, formulär, API-anrop och instruktioner. De är byggda för att vara tillgängliga och för att svara. Det är deras uppdrag. Och det är just därför de är så attraktiva att angripa.
Det räcker inte att skydda vägen fram till applikationen. Man måste också skydda det som händer när någon väl är framme.
Därför behövs ett extra skyddslager direkt framför och i applikationen. Ett skydd som förstår applikationens struktur, dess funktioner och dess normala användningsmönster. Ett skydd som kan skilja mellan legitim användning och avvikande beteende, och som skyddar oavsett om trafiken kommer från internet, från en intern användare eller via ett maskin-till-maskin-anrop genom ett API.
Applikationssäkerhet handlar alltså inte bara om att stoppa externa angrepp.
Det handlar om att kraftigt begränsa påverkan på verksamheten – även när någon redan har tagit sig in.
När verksamheten i praktiken lever genom sina applikationer blir applikationssäkerhet inte ett tekniskt tillval.
Det blir en grundförutsättning för att kunna bedriva verksamhet digitalt.
Frågan är då inte om applikationer behöver ett eget skydd, utan hur det skyddet faktiskt ser ut.
Men hur ser ett sådant skydd ut i verkligheten?
3. Vad innebär applikationssäkerhet i praktiken?
Applikationssäkerhet handlar om att etablera ett särskilt skyddslager runt det som faktiskt skapar värde i verksamheten.
Om man ser på en traditionell IT-miljö finns det flera lager av skydd. Nätverk skyddas, servrar skyddas, identiteter skyddas. Allt detta är avgörande. Men applikationen, där affärslogiken lever och där data faktiskt bearbetas, behöver ett skydd som är anpassat just för den nivån.
I tekniska sammanhang talar man ibland om det sjunde lagret i OSI-modellen, applikationslagret. Det är där kommunikationen når sin slutdestination. Det är där funktioner anropas, data hämtas och instruktioner tolkas. Det är också där många moderna angrepp får sin effekt
Applikationssäkerhet är därför inte en del av nätverkskyddet. Det är ett specialiserat skydd för just applikationslagret.
Vad är OSI-modellen?
OSI-modellen är en referensmodell som delar in digital kommunikation i sju lager. De lägre lagren (1-4) hanterar nätverk och överföring, medan de högre lagren (5-7) och primärt det sjunde lagret, applikationslagret, är där applikationen tar emot, tolkar och bearbetar information.
När vi talar om applikationssäkerhet avser vi skydd på de översta lagerna, där affärslogik, funktioner och data faktiskt används.
I praktiken innebär det att man etablerar ett säkerhetslager framför applikationen som förstår hur den är tänkt att användas. Det analyserar varje förfrågan utifrån funktion, kontext och beteende. Inte bara varifrån trafiken kommer, utan vad den faktiskt försöker göra.
Det innebär att även trafik som i alla hänseenden ser legitim ut kan stoppas om den används på fel sätt. En användare kan vara korrekt inloggad och komma från rätt plats. Trafiken kan se helt normal ut ur ett nätverksperspektiv. Men om samma användare plötsligt börjar hämta stora mängder data, manipulera parametrar eller testa funktioner på ett ovanligt sätt, måste skyddet kunna reagera.
Eller så här…
Tänk dig att någon kliver in i banken med giltig legitimation. Allt ser korrekt ut. Personen står i kön som alla andra. När det är deras tur börjar de ställa frågor om andra kunders konton, försöker fylla i blanketter som inte gäller dem och ber om utdrag de inte har rätt till.
Inget av detta bryter mot entréreglerna. Personen är korrekt identifierad. Men beteendet är inte rimligt och utan tydliga kontroller och processer hade personen kunnat få ta del av information som personen inte alls var berättigat till egentligen.
Applikationssäkerhet fungerar som just den kontrollen. Den förstår sammanhanget och kan avgöra när något avviker från det normala eller bryter mot applikationens säkerhetsregler. Det är ett extra lager som omsluter affärslogiken och säkerställer att funktioner och data används på rätt sätt.
Det gör det möjligt att skydda verksamhetens kärna även när applikationen måste vara öppen och tillgänglig. Det ger en kontrollpunkt där man kan upptäcka avvikelser, stoppa kända angrepp och begränsa konsekvenserna om något går fel.
Det skapar trygghet att fortsätta utveckla och exponera digitala tjänster. När det finns ett specialanpassat skyddslager runt applikationerna blir digitalisering inte en riskfaktor, utan en kontrollerad möjlighet.
4. Checklista för ledning och styrelse
Hur ser vår applikationssäkerhet egentligen ut?
Den här checklistan är inte teknisk. Den är avsedd som stöd för dialogen mellan ledning och IT-/säkerhetsansvariga.
Om flera av dessa frågor är svåra att besvara är det ofta ett tecken på att applikationssäkerheten inte är tillräckligt strukturerad eller synlig på strategisk nivå.
Sju frågor för ledning och IT-/säkerhetsansvariga.
- Vet vi vilka applikationer och API:er som är exponerade mot internet – och vilka av dem som är mest affärskritiska?
Detta handlar inte bara om en teknisk inventering. Vi behöver förstå vilka system som är nåbara utifrån och samtidigt veta vilka som bär våra intäkter, hanterar känsliga kunddata eller driver våra kärnprocesser. Vet vi vilken påverkan ett avbrott eller dataintrång i dessa system skulle få för verksamheten?
- Har vi ett skydd som arbetar direkt mot våra applikationer – även de vi inte själva har utvecklat?
Brandväggar och identitetsskydd är viktiga, men de skyddar främst vägen fram till applikationen. Frågan är om vi har ett dedikerat skydd som förstår funktioner, parametrar och beteenden i själva applikationen.
Detta gäller inte bara egenutvecklade system. Förlitar vi oss enbart på det inbyggda skyddet i köpta system, molnapplikationer och SaaS-tjänster? Eller har vi en egen kontrollpunkt som skyddar hur dessa används i vår miljö?
Applikationssäkerhet handlar om att skydda verksamhetens användning av systemet – oavsett om det driftas lokalt, i molnet eller som en extern tjänst.
- Kan vi upptäcka när något ser legitimt ut – men används på fel sätt?
Många angrepp sker med giltiga konton, API-nycklar eller korrekt inloggade användare. Har vi förmåga att upptäcka avvikande mönster, masshämtningar av data eller automatiserat missbruk innan det utvecklas till en incident med affärspåverkan?
- Kan vi snabbt minska risken om en sårbarhet upptäcks i ett affärskritiskt system?
Om en brist identifieras i en affärskritisk applikation, kan vi då införa ett tillfälligt skydd medan en permanent lösning utvecklas? Eller är vi exponerade under hela tiden som det tar att uppdatera kod och testa förändringar?
- Är ansvaret för applikationssäkerhet tydligt förankrat på ledningsnivå?
Vem ansvarar för applikationernas säkerhet? I många organisationer faller skyddet i glappet mellan utveckling, IT-drift och ”säkerhet”? En gemensam struktur och tydligt ägarskap måste finnas på plats. Applikationerna är verksamheten. Är då även skyddet av dem behandlat som en verksamhetsfråga, och inte enbart som en teknisk detalj?
- Har vi affärskritiska äldre system som inte längre aktivt utvecklas eller stöds?
Många organisationer har applikationer som fortfarande fungerar tekniskt men som saknar aktiv leverantör, uppdateringar eller intern kompetens. Dessa system kan vara svåra att ersätta och därför fortsätta användas år efter år.
Frågan är om vi har en tydlig strategi för hur dessa ska skyddas, isoleras eller på sikt ersättas. När kod inte längre underhålls blir ett externt skyddslager ofta den enda realistiska möjligheten att minska risken utan att stoppa verksamheten.
- Har vi faktisk visibilitet över vilka attacker som riktas mot våra applikationer – och vilken påverkan de skulle kunna få?
Vet vi hur många angreppsförsök som riktas mot våra publika gränssnitt och API:er i dag? Kan vi se vilka funktioner som testas, om någon försöker manipulera parametrar eller om masshämtning av data sker?
Och viktigare: förstår vi vilken affärspåverkan dessa försök skulle kunna få om de lyckades?
Utan tydlig visibilitet är det svårt att prioritera rätt åtgärder och investeringar. Applikationssäkerhet handlar inte bara om att ha skydd på plats – utan om att förstå hur hotbilden faktiskt ser ut i den egna miljön.
5. Hur ser hoten ut i praktiken?
För att förstå varför ovan frågor är så avgörande och för att fullt ut förstå varför applikationen behöver ett eget skydd behöver vi också förstå hur hotbilden faktiskt ser ut på applikationsnivå. Låt oss därför titta på hur applikationer faktiskt angrips.
Det är viktigt att börja med en nyansering. Alla angrepp är inte riktade. Den stora majoriteten av attacker på internet är automatiserade och opportunistiska. Cyberkriminella aktörer skannar brett efter svagheter som läckta konton, öppna fjärranslutningar, missade säkerhetsuppdateringar eller felkonfigurerade system. De slår till där de hittar en öppning.
Men man letar också efter svagheter direkt i de system och applikationer som exponeras över internet. Hittar man en väg in där behöver man inte ta sig genom den underliggande IT-miljön. Man är redan inne där verksamhetens värde ofta finns.
Det finns dessutom angripare som specialiserat sig på detta lager och som systematiskt och automatiserat letar efter svagheter i just applikationer.
När man analyserar verkliga intrång ser man ett tydligt mönster. Angripare går sällan runt applikationen. De går genom den. De använder dess funktioner, formulär och API:er, fast på ett sätt som applikationen inte var tänkt att hantera.
Det är därför organisationer med starkt nätverksskydd och god identitetshantering ändå kan drabbas av allvarliga incidenter. Skyddet runt omkring fungerar, men applikationen i sig används på fel sätt.
Internationella ramverk och branschrapporter pekar på samma sak. En av de mest etablerade referenserna är OWASP, Open Worldwide Application Security Project, som regelbundet sammanställer de vanligaste och mest kritiska sårbarheterna i webbapplikationer.
OWASP visar vilka typer av svagheter som gång på gång utnyttjas i applikationer. Bristande åtkomstkontroll, injektionsangrepp, osäker design, felkonfigurationer och sårbarheter kopplade till API:er är återkommande mönster.
Gemensamt för dessa risker är att de utnyttjar funktioner och logik – inte nätverksinfrastrukturen i sig.
Många av dessa ”svagheter” kan och bör man såklart adressera direkt i applikationens kod. Men i en del fall handlar det om fel och misstag i koden, i andra fall handlar det om att man använder sig av en extern standardmodul i koden som senare visar sig ha sårbarheter och ibland handlar det om att man inte haft fullt fokus på säkerheten av olika anledningar. I praktiken är det få applikationer som är ”perfekt” kodade från ett säkerhetsperspektiv. Det innebär att man istället får implementera teknik som kontrollerar hur applikationen används. Det går att göra proaktivt men måste också göras i realtid i varje session.
I detta kapitel tittar vi närmare på de vanligaste angreppssätten.
5.1 När någon gör mer än de borde - Bristande åtkomstkontroll (Broken Access Control)
Detta är i dag en av de vanligaste orsakerna till intrång genom en applikation.
En användare är korrekt inloggad, men applikationen kontrollerar inte tillräckligt noggrant vad användaren faktiskt får göra. Det kan handla om att ändra en parameter i en adressrad och därmed få tillgång till någon annans information. Det kan handla om att anropa en funktion som egentligen är avsedd för administratörer.
Eller så här…
Tänk dig att någon har giltigt passerkort till banken. De får komma in i byggnaden. Men genom att prova olika dörrar upptäcker de att även ledningens kontor och serverhallen går att öppna.
Ingen har brutit sig in. Men ingen har heller stoppat dem.
Det här är ett typiskt exempel på varför applikationen behöver förstå vad en användare får göra, inte bara vem användaren är.
Så vad kan man göra för att undvika detta?
Detta är så klart först och främst en sak som bör åtgärdas i applikationen uppbyggnad så att roller och behörigheter används och kontrolleras på ett korrekt sätt. Dvs du skall aldrig ha tillgång till något mer än vad du behöver för din roll, som t ex kund, handläggare eller administratör. Man pratat ofta om “Principle of Least Privilege” i dessa sammanhang.
Men, genom att använda avancerad applikationsnära åtkomstkontroll där varje funktion, varje anrop och varje session kontrolleras i realtid skapar man ett extra skydd. Det hade gett effekten att varje rum i exemplet ovan hade haft sitt eget lås och man hade dessutom larmat om ett passerkort testats på flera dörrar där man inte har access. Passerkortet hade fungerat i entrén men inte automatiskt överallt.
Tekniskt sett hanteras denna risk genom att etablera en så kallad Webbapplikationsbrandvägg (WAF) som arbetar med kontextbaserad kontroll på applikationsnivå. Applikationsbrandväggen analyserar och tolkar bland annat förfrågningar och olika parametrar samt kopplar dem till användarens session och roll.
I en modern säkerhetsplattform för applikationer, en så kallad Application Delivery and Security Platform (ADSP), sker detta genom ”Layer 7-inspektion”. Det innebär att åtkomst inte bara bedöms utifrån autentisering, utan även utifrån vilken funktion, vilket objekt och vilken metod som anropas. Även legitima användare kan därmed stoppas om de försöker göra något de inte är avsedda att göra.
5.2 När systemet litar för mycket på frågor och instruktioner - Kodinjektion (Injection, exempelvis SQL Injection)
En annan vanlig attackform är att angriparen skickar in data som applikationen inte förväntar sig. Injection innebär att applikationen inte tydligt skiljer mellan data och instruktioner. Om användarens inmatning inte kontrolleras korrekt kan systemet börja tolka data som kommandon.
Det kan leda till att databaser lämnar ut information eller att funktioner utför åtgärder som aldrig var avsedda.
Eller så här…
Tänk dig att du lämnar en lapp till banken med instruktionen att flytta pengar. I slutet av texten har du lagt till en extra rad som ber banken visa alla kunders saldon. Om banken följer lappen ord för ord uppstår ett allvarligt problem. I verkligheten hade nog detta aldrig hänt, men datorer och system är i grunden programmerade att utföra de order som vi ger dem.
Med ett modernt applikationsskydd som analyserar varje förfrågan på djupet och skiljer på normal/förväntad input och skadliga/oväntade mönster skulle banken i stället läsa hela lappen, förstå vad som hör till en legitim transaktion och ignorera resten. Transaktionen genomförs, men inget mer.
Tekniskt sett kräver detta en säkerhetsfunktion som kan inspektera trafik på applikationsnivå och analysera innehållet i varje parameter innan den når databasen eller affärslogiken.
I en ADSP sker detta genom en WAF-motor som kombinerar signaturbaserad detektion av kända injektionsmönster med beteendebaserad analys av avvikande input.
Plattformen kan även arbeta med en positiv säkerhetsmodell där endast förväntade parametrar och datatyper accepteras. Skadliga instruktioner blockeras då i realtid, även om de är modifierade eller delvis obekanta.
5.3 När applikationen används för att lura användaren - Cross-Site Scripting (XSS)
I vissa fall är det inte själva systemet som manipuleras, utan användaren.
Cross-Site Scripting innebär att applikationen återger innehåll utan att säkerställa att det är säkert. Angriparen lyckas få in skadlig kod som sedan körs i användarens webbläsare, men det ser ut som om den kommer från den legitima applikationen.
För användaren är det omöjligt att skilja på vad som är äkta och vad som är manipulerat.
Eller så här…
I bankens foajé sitter en klassisk informationstavla. Någon lyckas sätta upp en falsk instruktion som uppmanar kunder att skanna en QR-kod och ange sina bankuppgifter för att förbereda sitt ärende. Instruktionen sitter i bankens lokaler, så kunden litar på den.
I praktiken har kunden lämnat känslig information till någon utomstående.
Digitalt fungerar det på samma sätt. Om applikationen inte kontrollerar vad som får visas eller köras i användarens webbläsare kan den utnyttjas för att sprida skadlig kod eller samla in information.
Så vad kan man göra för att undvika detta?
För att motverka Cross-Site Scripting (XSS) krävs ett skydd som inte bara analyserar inkommande trafik, utan även kontrollerar vad som skickas tillbaka till användaren.
I en ADSP sker detta tekniskt sett genom inspektion av både request och response på Layer 7-nivå. Plattformen identifierar script-injektioner, manipulerade parametrar och försök att exekvera otillåten kod i webbläsaren. I mer avancerade implementationer kan även klientnära skydd användas för att förhindra att obehöriga scripts exekveras i användarens session.
Det innebär att skadligt innehåll stoppas innan det når webbläsaren, även om det finns brister i applikationens egen kod.
Med ett sådant skydd på plats tas den falska skylten bort innan någon hinner läsa den.
5.4 När designen i sig går att utnyttja - Osäker design (Insecure Design)
Alla risker handlar inte om kodfel. Ibland fungerar systemet exakt som det är byggt. Problemet är att designen inte tog höjd för hur funktionen kan missbrukas.
Insecure Design innebär att affärslogiken saknar begränsningar eller kontroller. Funktionen fungerar, men det finns inga spärrar mot orimlig användning.
Eller så här…
Tänk dig att banken lanserar en kampanj:
“Rekommendera en vän och få 500 kronor i bonus.”
Systemet är korrekt byggt. Varje ny registrering ger en bonus. Men ingen har satt en gräns för hur många gånger samma person kan få ersättning.
En person automatiserar registreringar och skapar hundratals falska konton. Allt ser tekniskt korrekt ut. Bonusen betalas ut varje gång.
Systemet är inte hackat.
Det är designen som utnyttjas.
När det handlar om osäker design räcker det inte med statiska signaturer. Man behöver dels införa hårda kontroller över vad som får kommunicera med vad, och vad systemen får göra med den kommunikation som tillåts. Men eftersom detta handlar om att ta höjd för saker man inte tänkt på, så behöver man även analysera hur funktioner kan missbrukas, inte bara hur de ska användas. Dvs man behöver i många fall analysera det från ett annat perspektiv och ofta även införa rimliga begränsningar, övervaka beteendemönster och reagera på avvikelser.
I en applikationssäkerhetsplattform (ADSP) används beteendeanalys och anomalidetektion för att identifiera avvikande användningsmönster. Plattformen kan tillämpa begränsning av anropsfrekvens och datamängd, automatiseringsskydd och skydd mot bot-trafik för att stoppa massregistreringar och systematiskt missbruk av affärslogik.
Det innebär att även funktioner som är korrekt byggda kan skyddas mot överdriven eller automatiserad användning. Det är skillnaden mellan att bygga något som fungerar och att bygga något som är robust.
5.5 När API:er blir bakvägen in - API-relaterade sårbarheter (API Security Risks)
Nästan alla applikationer använder idag API:er för att integrera med gränssnitt och andra system. API:er är byggda för snabb och direkt maskin-till-maskin-kommunikation och har ofta direkt tillgång till affärslogik och data. Många publika molntjänster erbjuder sk “Öppna API:er” som man kan använda för att bygga funktioner med eller för att direkt koppla till andra system (t ex om man vill koppla ihop lönesystemet med ett separat tidsredovisningssystem).
Just därför kan de bli en genväg in i verksamhetens kärna om de inte skyddas ordentligt. Oftast krävs det någon form av “nyckel” för att du skall få tillåtelse att kommunicera med ett specifikt system/applikation.
Eller så här…
Banken har en bemannad entré för anställda. Där sker strikt identifiering och kontroll. Men på baksidan finns ett lastintag byggt för effektivitet och stora volymer. Om kontrollen där enbart består av att visa upp ett passerkort från en betrodd budfirma blir det en attraktiv väg in.
API:er fungerar likadant. De är effektiva och kraftfulla. Utan rätt kontroller kan de användas för att hämta stora datamängder eller automatisera missbruk.
Vad är ett API?
Ett API, Application Programming Interface, är ett gränssnitt som gör det möjligt för till exempel applikationer och visuella gränssnitt kommunicera att med varandra. När någon klickar på en knapp i ett gräsnsnitt (t ex en webbsida eller mobil-app) så skickas en tydligt strukturerad begäran direkt till applikationen, enligt ett förutbestämt format. Det behöver inte bara vara mellan applikationer och visuella gränssnitt, utan det kan även vara direkt mellan olika applikationer på systemnivå, det vi ofta kallar “systemintegrationer”.
API:er är grunden för integrationer, molntjänster, automatisering och modern app-utveckling.
När API-nyckeln blir enda skyddet
Många system använder statiska API-nycklar som autentisering. Har du en giltig nyckel betraktas du som betrodd och inga ytterligare kontroller utförs. I många miljöer är nyckeln fortfarande den enda säkerhetsmekanismen. Den fungerar som både identifiering och behörighet i samma sträng, där det enda skyddet är att den är tillräckligt lång och komplex för att inte kunna gissas.
Av säkerhetsskäl visas nyckeln ofta bara en gång när den skapas. Därefter går den inte att läsa ut igen. I praktiken leder det dock ofta till att den sparas i dokument, mejl, konfigurationsfiler eller kod. Om nyckeln hamnar fel finns det ofta ingen ytterligare kontroll.
Systemet behöver inte hackas. Har du fått tag på nyckeln, så är du inne.
Detta gäller inte enbart direkt systemgenererade API-nycklar.
I moderna identitetsplattformar, exempelvis Microsoft Entra ID, finns en viktig skillnad mellan applikationer som agerar i en användares namn och applikationer som agerar med egna systemrättigheter när de skall kommunicera med till exempel en annan applikation.
När ett API anropas med en applikationsidentitet – exempelvis via just en API-nyckel, kan den identiteten ges mycket breda behörigheter, utan någon mänsklig kontext som begränsar åtkomsten. Lite som en huvudnyckel som ger tillträde till hela fastigheten – effektiv, men en stor risk om den hamnar i fel händer.
Om en sådan nyckel eller identitet komprometteras kan påverkan bli omfattande, trots att autentiseringen (eller ”nyckeln”) är helt korrekt i sig.
Det visar varför API-säkerhet inte bör bygga enbart på giltig nyckel. Även legitima anrop måste kontrolleras utifrån beteende, omfattning och användningsmönster.
För att minska risken behöver API:er behandlas som en egen attackyta.
Det krävs flera kontrollnivåer. Det kan handla om att begränsa vilka funktioner en nyckel får använda, hur ofta anrop får göras och hur stora datamängder som kan begäras. Det handlar också om att validera att anropen följer en definierad struktur och att upptäcka avvikande beteenden, även när autentiseringsuppgiften i sig är giltig.
I en ADSP sker detta genom en API-säkerhetsfunktion som kan validera anrop mot definierade scheman, kontrollera datatyper och parametrar samt begränsa frekvens och datamängd per klient.
Plattformen kan dessutom analysera hur en API-nyckel eller token används över tid och identifiera när en legitim autentiseringsuppgift utnyttjas på ett sätt som avviker från det normala. På så sätt räcker det inte att enbart ha tillgång till nyckeln.
API:er är nödvändiga för modern digitalisering. Men de måste skyddas med samma noggrannhet som det publika gränssnittet.
5.6 När dörren är låst - men fönster står öppet - Felaktig säkerhetskonfiguration (Security Misconfiguration)
Alla incidenter beror inte på avancerade attacker. Ofta handlar det om något så enkelt som en felaktig inställning.
Security Misconfiguration innebär att applikationen eller dess plattform inte är korrekt konfigurerad. Det kan röra sig om standardinställningar som aldrig ändrats, administrativa gränssnitt som är exponerade, onödiga funktioner som är aktiverade eller molnresurser som är åtkomliga från internet.
Eller så här…
Banken har säkra entrédörrar och larm. Men ett fönster på baksidan står öppet eftersom någon glömde stänga det efter en renovering.
Ingen har brutit upp något. Det var bara en inställning som aldrig kontrollerades.
Digitalt ser det likadant ut. Ett admin-gränssnitt som är publikt. En lagringsyta utan rätt åtkomst. En testmiljö som råkat exponeras.
Systemet fungerar. Men det är öppet på fel sätt.
Felkonfigurationer kan aldrig elimineras helt, vilket gör det viktigt med ett skydd som kompenserar för det. Man behöver arbeta strukturerat med säker konfiguration och löpande kontroll. Ta bort standardinställningar, begränsa åtkomst, stäng av det som inte används och verifiera regelbundet att miljön ser ut som den ska.
I en ADSP kan central policyhantering och applikationsnära trafikinspektion användas för att blockera kända exploateringsmönster även om den underliggande applikationen eller plattformen är felkonfigurerad. Plattformen kan även tillämpa så kallad virtual patching, där sårbarheter blockeras på trafiknivå utan att applikationen behöver ändras direkt.
Det innebär att säkerheten inte enbart är beroende av att varje inställning är korrekt från början.
6. Det gemensamma mönstret och vad som krävs för att möta det
Om vi betraktar dessa exempel tillsammans framträder ett tydligt mönster. Ingen av attackerna kräver att någon tar sig förbi brandväggen med avancerade verktyg. I de flesta fall används applikationen precis som den är byggd, men på ett sätt som inte var tänkt.
Det handlar om att göra mer än man borde. Att kunna skicka in mer än systemet förväntar sig. Att kunna utnyttja affärslogik utan begränsningar, använda integrationer utan tillräcklig kontroll eller hitta en inställning som aldrig granskades.
Gemensamt är att angreppen sker där verksamheten möter omvärlden.
Det är därför applikationssäkerhet inte kan reduceras till en teknisk detalj. Det är ett skydd för verksamhetens kärna. Och det är också därför traditionellt nätverksskydd inte räcker. Det skyddar anslutningen – men inte affärslogiken.
Frågan är alltså inte om applikationen ska vara tillgänglig. Den måste vara det. Frågan är hur vi säkerställer att den bara används på rätt sätt.
I ett hotlandskap som förändras snabbt räcker det inte med statiska regler och fasta signaturer. Skyddet måste kunna upptäcka avvikelser, anpassa sig efter nya mönster och reagera i realtid när något inte beter sig som det ska.
I dag hanteras detta ofta genom att etablera en modern säkerhetsplattform för applikationer, även kallad Application Delivery and Security Platform (ADSP).
En ADSP samlar flera viktiga skyddsfunktioner i ett och samma lager framför applikationen. Det gör att man kan inspektera trafik på applikationsnivå, förstå kontext och beteende, och tillämpa säkerhet konsekvent över flera applikationer och miljöer. Det gör också att skyddet kan följa applikationen oavsett om den är placerad lokalt, i molnet eller distribuerad över flera miljöer.
Poängen är inte att lägga på fler fristående verktyg. Poängen är att skapa ett skydd som kontinuerligt anpassar sig efter hur applikationen används och hur hotbilden förändras. Vilket med fördel görs genom att etablera en gemensam kontrollpunkt där säkerheten blir en del av hur applikationen levereras, används och skyddas i vardagen.
Cuebid har lång erfarenhet av att designa och implementera denna typ av arkitektur i komplexa miljöer och är en av få aktörer i Norden som utbildar inom en av världens ledande plattformar för Application Delivery and Security.
För oss handlar det inte om en produkt. Det handlar om att bygga en säker och robust digital grund där verksamheten kan fortsätta utvecklas utan att exponeras i onödan.
7. Vem äger skyddet runt applikationen?
Här uppstår ofta en gråzon.
Utvecklingsteamet bygger applikationen. IT ansvarar för infrastrukturen. Säkerhetsteamet arbetar med policy, övervakning och incidenthantering. Alla gör viktiga saker, men skyddet precis framför applikationen hamnar lätt mellan stolarna.
Det är också därför applikationssäkerhet inte bara är en teknisk fråga. Det är en organisatorisk förmåga. Man behöver en gemensam struktur där skyddet blir konsekvent, upprepningsbart och enkelt att förvalta, i stället för att uppfinnas på nytt i varje projekt.
En modern säkerhetsplattform för applikationer, en ADSP, kan fungera som en sådan gemensam grund. Den skapar en tydlig kontrollpunkt framför applikationerna där policy kan tillämpas centralt, där avvikelser kan upptäckas och där skyddet kan följa applikationen även när den flyttar mellan miljöer. Det gör ansvaret tydligare och minskar beroendet av att varje team ska bygga sin egen säkerhet från grunden.
När detta fungerar blir det också enklare att samarbeta. Utveckling kan fortsätta leverera, IT kan fortsätta drifta och säkerhet kan fortsätta styra och övervaka, men med ett skyddslager som är gemensamt och som fångar upp risker innan de blir incidenter.
8. Affärsvärdet
När applikationssäkerhet fungerar märks det sällan i vardagen. Användare arbetar som vanligt, kunder möter samma gränssnitt och integrationer fortsätter att fungera.
Skillnaden ligger i kontrollen.
I dagens hotlandskap kan man inte förlita sig på statiska skyddsmurar. Angripare arbetar automatiserat, systematiskt och affärsdrivet. De testar kontinuerligt nya angreppssätt, kombinerar tekniker och anpassar sig snabbt när ett skydd förändras. Hotbilden är inte statisk. Den är adaptiv.
Därför måste skyddet också vara adaptivt.
Ett modernt applikationsskydd analyserar beteenden i realtid, identifierar avvikelser och reagerar när något inte följer det normala användningsmönstret, även om attacken inte matchar en känd signatur. Det handlar om kontinuerlig riskreduktion snarare än punktinsatser.
När säkerheten arbetar dynamiskt i bakgrunden skapas digital resiliens. Organisationen blir bättre på att upptäcka, begränsa och återhämta sig från incidenter utan att verksamheten stannar upp.
Risker fångas upp innan de utvecklas till större incidenter. Sårbarheter kan hanteras genom virtuellt skydd medan en permanent lösning tas fram. API:er kan exponeras utan att hela verksamheten exponeras samtidigt.
Det är detta som är det verkliga affärsvärdet. Inte bara minskad risk, utan ökad förmåga att fortsätta utvecklas i ett föränderligt hotlandskap.
9. Framtiden och regelverk
Den digitala exponeringen ökar i alla branscher, och samtidigt skärps kraven från myndigheter, kunder och samarbetspartners. Regelverk som NIS2 är tydliga exempel på att förväntningarna på systematiskt och riskbaserat säkerhetsarbete höjs.
Men regelverken är inte slutmålet i sig. De är en spegling av verkligheten: hotlandskapet förändras snabbt. Angripare hittar löpande nya sätt att exploatera applikationer, automatisera attacker och pressa organisationer ekonomiskt med krav på lösen eller datautpressning. Att då förlita sig på statiska skydd som bara står på plats är inte tillräckligt för att möta dagens och morgondagens risker.
Organisationer behöver bygga sin cybersäkerhet som en kapacitet, inte som en punktlösning. Det innebär att ha tre fundamentala förmågor som utvecklas och fördjupas över tid: att skydda, att upptäcka och att hantera.
Att skydda betyder inte bara att ha en brandvägg eller ett skyddslager. Det handlar om att minimera attackytan, motverka intrångsförsök och begränsa möjligheten för en angripare att röra sig fritt om denne väl tagit sig in. Ett starkt skydd gör det svårare för hotaktörer att lyckas och ökar samtidigt tiden för att upptäcka när något är fel.
Att upptäcka innebär förmågan att se det som inte borde hända, snabbt och effektivt genom övervakning, larm, korrelation av händelser och realtidsanalys. Det handlar om att kunna urskilja avvikande beteenden i ett konstant brus av data, så att små signaler inte drunknar i mängden och missas.
Och att hantera innebär att organisationen är förberedd på vad som ska göras när en incident faktiskt inträffar. Det räcker inte att upptäcka en attack; man måste kunna reagera metodiskt och kraftfullt, minimera skada, kommunicera tydligt och återgå till normal verksamhet.
Denna helhet, att skydda, upptäcka och hantera, är grunden för digital resiliens. Det är den förmågan som gör att en organisation kan fortsätta att leverera affärsvärde även när hotbilden förändras eller ovanliga mönster uppstår.
Organisationer som har byggt upp dessa förmågor står starkare, inte bara ur ett tekniskt perspektiv utan också ur ett regulatoriskt och affärsmässigt. De kan visa att skyddet inte är en punktlösning utan en adaptiv, kontinuerligt förbättrad kapacitet som speglar hur verkliga angrepp sker.
I en värld där både hot och affärsmodeller utvecklas snabbt är detta inte bara en säkerhetsfråga, det är en strategisk förmåga.
10. Sammanfattning
Applikationen är inte längre bara en del av IT-miljön. Den är verksamheten.
Det är där affärslogiken finns. Det är där kunder möter er och där data skapas, bearbetas och delas. Och det är därför det också är där angripare riktar sitt fokus.
Traditionellt IT-skydd är nödvändigt. Brandväggar, segmentering, identitetshantering och övervakning utgör grunden i en modern säkerhetsarkitektur. Men dessa skydd är i första hand byggda för att kontrollera vad som får ansluta och vad som ska stoppas. De skyddar vägen fram till applikationen.
Applikationen däremot är konstruerad för att vara tillgänglig. Den ska ta emot trafik, instruktioner och integrationer. Den ska svara.
Det innebär att säkerheten måste flyttas dit affären faktiskt sker. Den måste förstå funktioner, parametrar, beteenden och integrationer. Den måste kunna skilja mellan legitim användning och missbruk, även när trafiken ser korrekt ut på ytan.
I dagens hotlandskap räcker det inte med statiska skyddsmurar. Angripare utvecklar kontinuerligt nya metoder för att ta sig in och för att pressa organisationer på pengar. Ett modernt applikationsskydd måste därför vara dynamiskt. Det behöver kunna identifiera avvikande mönster, reagera i realtid och hantera hot som inte exakt matchar gårdagens attackmönster.
Applikationssäkerhet handlar därför inte om att bromsa digitalisering. Det handlar om att möjliggöra den på ett kontrollerat sätt. Det handlar om att skydda verksamhetens kärna, upptäcka avvikelser i tid och hantera incidenter utan att förlora kontrollen.
När säkerheten följer applikationen kan organisationen fortsätta utvecklas, exponera nya tjänster och bygga nya integrationer utan att attackytan växer okontrollerat.
11. Vill ni veta hur er applikationssäkerhet faktist står sig?
Många organisationer utgår från att applikationen är skyddad eftersom infrastrukturen är det. I praktiken är det ofta i applikationslagret som de största riskerna finns.
Cuebid arbetar med att stärka organisationers cybersäkerhetsförmågor genom att hjälpa dem att skydda, upptäcka och hantera risker i den digitala kärnan. Det innebär att vi analyserar den faktiska exponeringen, identifierar sårbarheter i applikationslagret och designar ett sammanhållet skydd som är anpassat efter verksamhetens behov och riskprofil.
Om ni vill få en tydlig bild av hur er applikationssäkerhet faktiskt står sig i dag och hur ett modernt och dynamiskt skydd skulle kunna se ut i er miljö är ni välkomna att kontakta oss för ett förutsättningslöst samtal.
Digitalisering ska vara en konkurrensfördel. Med rätt skydd blir den också det.
12. Förklaringar och begrepp
ADSP – Application Delivery and Security Platform
En modern säkerhetsplattform för applikationer som kombinerar funktioner som webbapplikationsbrandvägg, API-skydd, bot-skydd och beteendeanalys i ett gemensamt lager framför applikationen.
API – Application Programming Interface
Ett tekniskt gränssnitt som gör det möjligt för olika system att kommunicera med varandra. I stället för att en människa klickar i ett gränssnitt skickar ett system en strukturerad begäran direkt till applikationen.
Broken Access Control
Bristande åtkomstkontroll. En sårbarhet där en användare kan göra mer än den borde, exempelvis komma åt data eller funktioner som egentligen är avsedda för någon annan.
Cross-Site Scripting (XSS)
En sårbarhet där angriparen lyckas få applikationen att visa eller köra skadlig kod i användarens webbläsare. För användaren ser det ut som om informationen kommer från den legitima applikationen.
Injection (till exempel SQL Injection)
En attack där skadlig kod eller instruktioner skickas in via formulär eller parametrar och tolkas av applikationen som giltiga kommandon.
OSI-modellen och ”Lager 7”
En referensmodell som beskriver hur nätverkskommunikation är uppdelad i sju lager, från fysisk överföring till applikationsnivå.
Lager 7 – Applikationslagret
Detta är det lager som användaren möter.
Här finns exempelvis webbläsaren, e-postprogrammet eller en mobilapp. Det är här information visas, funktioner används och data tolkas. Det är också här affärslogiken finns – det vill säga där verksamhetens tjänster faktiskt lever.
Lager 6 – Presentationslagret
Ser till att informationen är i rätt format.
Det kan handla om att översätta data så att mottagaren förstår den, samt att kryptera och dekryptera information så att den skyddas under överföringen.
Lager 5 – Sessionslagret
Håller ordning på kommunikationen mellan två parter.
Det öppnar en “session”, ser till att den hålls igång så länge det behövs och stänger den när kommunikationen är klar.
Lager 4 – Transportlagret
Ansvarar för att informationen faktiskt kommer fram korrekt.
Det delar upp data i mindre delar, ser till att inget tappas bort och begär om något behöver skickas igen.
Lager 3 – Nätverkslagret
Bestämmer vilken väg informationen ska ta genom nätverk för att nå rätt destination. Här används IP-adresser för att hitta fram.
Lager 2 – Datalänklagret
Hanterar kommunikationen inom samma nätverk, till exempel inom ett kontor eller en servermiljö.
Lager 1 – Fysiska lagret
Det handlar om den faktiska infrastrukturen – kablar, trådlösa signaler och hårdvara som överför data som elektriska signaler eller radiovågor.
OWASP – Open Worldwide Application Security Project
En internationell organisation som sammanställer och publicerar kunskap om säkerhet i webbapplikationer. OWASP Top 10 är en av de mest använda referenserna för vanliga applikationssårbarheter.
Security Misconfiguration
Felaktig säkerhetskonfiguration. Uppstår när system, plattformar eller applikationer är felinställda, till exempel genom öppna administrationsgränssnitt eller kvarlämnade standardinställningar.
Virtual Patching
En metod där sårbarheter blockeras på trafiknivå i ett säkerhetslager framför applikationen, utan att själva applikationen behöver ändras direkt.
WAF – Web Application Firewall
En webbapplikationsbrandvägg som analyserar och filtrerar trafik till och från en applikation på applikationsnivå, i syfte att stoppa attacker som riktar sig mot funktioner och data.
Fyll i formuläret så kontaktar vi dig så fort vi kan!
Vanligtvis inom 8 timmar (kontorstid).
