From 370c41b2670142a3455967ef8dd8df049c1de904 Mon Sep 17 00:00:00 2001 From: "loyd.nathalie@gmail.com" Date: Wed, 27 May 2026 13:45:20 +0200 Subject: [PATCH 01/46] =?UTF-8?q?inl=C3=A4mning?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- planeringsfasen.md | 54 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 661cae0e..b7cae19f 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1 +1,53 @@ -# Inlämning 1 - Planeringsfasen \ No newline at end of file +# Inlämning 1 - Planeringsfasen +Browser: 0 +Frontend: 1 +Express/Backend: 1 +Databas: 5 + +Om tillitsgränserna: +Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. + +Pilarna (T & I): +De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. + +Kopplingen till våra säkerhetskrav: +Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker via krypterad HTTPS. Och eftersom vi vet att vi inte kan lita på Frontend-boxen (eftersom den ligger i den osäkra zonen), har vi lagt ett strikt säkerhetskrav på att Express/Backend måste göra all indatavalidering och behörighetskontroll innan något sparas i Databasen. + + +1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) +Utifrån din skiss och ESTRID-klassificeringen identifieras följande hotscenarier: + + +Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) +Scenario: När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. + +Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express +Scenario: Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. + +Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) +Scenario (E): En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). + +Scenario (D): En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. + +Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data +Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. + +2. Fyra säkerhetskrav formulerade i kravspecifikationen +För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: +· Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) +Formulering: Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. + + + +· Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) +Formulering: Express-backenden ska validera och sanera (rensa) all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. + + + +· Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) +Formulering: Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. + + + +· Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) +Formulering: Express-API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot överbelastning (Denial of Service) och automatiserade brute force-attacker. \ No newline at end of file From 28174c5fd5796cb1dddb571e179cc8d4e3c80e66 Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Wed, 27 May 2026 13:49:39 +0200 Subject: [PATCH 02/46] Ett test --- planeringsfasen.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index b7cae19f..d5008679 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,3 +1,5 @@ +Jag testar för att se om ni kan läsa detta? + # Inlämning 1 - Planeringsfasen Browser: 0 Frontend: 1 @@ -50,4 +52,4 @@ Formulering: Användaren ska i inloggat läge endast kunna redigera och radera s · Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) -Formulering: Express-API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot överbelastning (Denial of Service) och automatiserade brute force-attacker. \ No newline at end of file +Formulering: Express-API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot överbelastning (Denial of Service) och automatiserade brute force-attacker. From b57b0843e40f9b189d2aa3e3a9adf45ba5a044c4 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 13:52:21 +0200 Subject: [PATCH 03/46] Test changes in planeringsfasen.md --- planeringsfasen.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/planeringsfasen.md b/planeringsfasen.md index d5008679..0d6d90be 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,5 +1,7 @@ Jag testar för att se om ni kan läsa detta? +Nu testar jag att ändra + # Inlämning 1 - Planeringsfasen Browser: 0 Frontend: 1 From 6f3aedadf8fb3eb367ecca6790abffb996ad8a59 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 14:21:06 +0200 Subject: [PATCH 04/46] Clean up planeringsfasen.md Removed test lines and updated content structure. --- planeringsfasen.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 0d6d90be..9fcd1553 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,8 +1,5 @@ -Jag testar för att se om ni kan läsa detta? - -Nu testar jag att ändra - # Inlämning 1 - Planeringsfasen + Browser: 0 Frontend: 1 Express/Backend: 1 From aef277d8c6a87dcabe7672c37ba95355b6d115a8 Mon Sep 17 00:00:00 2001 From: nat316 Date: Wed, 27 May 2026 14:24:49 +0200 Subject: [PATCH 05/46] Improve readability of trust boundary Reformatted text for better readability by breaking long sentences into shorter ones. --- planeringsfasen.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 9fcd1553..e06e09e9 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -6,7 +6,11 @@ Express/Backend: 1 Databas: 5 Om tillitsgränserna: -Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. +Vi har delat upp systemet med två tydliga tillitsgränser. +Allt till vänster, Browser/Frontend, körs på användarens egen enhet. +Det betyder att det är en osäker miljö som vi inte kan kontrollera. +Användaren kan öppna Developer Tools och ändra i koden om de vill. +Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. Pilarna (T & I): De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. From 297da1974c8d2c96d010771021e1d06c0286dc57 Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Wed, 27 May 2026 14:26:37 +0200 Subject: [PATCH 06/46] Fixat browser och frntend --- planeringsfasen.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/planeringsfasen.md b/planeringsfasen.md index e06e09e9..7b5861aa 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,8 +1,11 @@ # Inlämning 1 - Planeringsfasen Browser: 0 + Frontend: 1 + Express/Backend: 1 + Databas: 5 Om tillitsgränserna: From c5da7d676f1990df9672e4f2339f23f1135bbe5b Mon Sep 17 00:00:00 2001 From: nat316 Date: Wed, 27 May 2026 14:28:10 +0200 Subject: [PATCH 07/46] Improve formatting of trust boundaries section Updated formatting for the section on trust boundaries. --- planeringsfasen.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 7b5861aa..f0fde1a4 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -8,7 +8,7 @@ Express/Backend: 1 Databas: 5 -Om tillitsgränserna: +Om tillitsgränserna: Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. From 36bad357ad4293313383a4067971d35b74a17b84 Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Wed, 27 May 2026 14:30:32 +0200 Subject: [PATCH 08/46] Adding break Added HTML break tag for formatting in the document. --- planeringsfasen.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index f0fde1a4..e511d759 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -8,12 +8,12 @@ Express/Backend: 1 Databas: 5 -Om tillitsgränserna: +Om tillitsgränserna: Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. -Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. +Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. Pilarna (T & I): De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. From cd83c4417daf4d0ae15931ab0a23d7e56a891dd6 Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Wed, 27 May 2026 14:31:14 +0200 Subject: [PATCH 09/46] Adding break Fixed HTML break tags in the text about trust boundaries. --- planeringsfasen.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index e511d759..a1288884 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -8,12 +8,12 @@ Express/Backend: 1 Databas: 5 -Om tillitsgränserna: +Om tillitsgränserna: Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. -Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. +Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. Pilarna (T & I): De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. From 51919c0688f241e5cb69429ccf306a2069ecd896 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 14:55:33 +0200 Subject: [PATCH 10/46] Format text with bold.md --- planeringsfasen.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index a1288884..15d7f4a7 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -9,20 +9,25 @@ Express/Backend: 1 Databas: 5 Om tillitsgränserna: + Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. -Pilarna (T & I): +Pilarna (T & I): + De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. -Kopplingen till våra säkerhetskrav: +Kopplingen till våra säkerhetskrav: + Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker via krypterad HTTPS. Och eftersom vi vet att vi inte kan lita på Frontend-boxen (eftersom den ligger i den osäkra zonen), har vi lagt ett strikt säkerhetskrav på att Express/Backend måste göra all indatavalidering och behörighetskontroll innan något sparas i Databasen. -1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) +1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) + + Utifrån din skiss och ESTRID-klassificeringen identifieras följande hotscenarier: From 92bca356ed8bfa4c225b1dce7ab4f5317aa9a96a Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 14:58:51 +0200 Subject: [PATCH 11/46] =?UTF-8?q?Utvecklat=20dok=20med=20tydliga=20gr?= =?UTF-8?q?=C3=A4nser?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updated security risks and requirements in the planning phase document, including detailed scenarios for identified threats and formulated security requirements to mitigate them. --- planeringsfasen.md | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 15d7f4a7..2447d9b5 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -27,40 +27,45 @@ Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker 1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) - -Utifrån din skiss och ESTRID-klassificeringen identifieras följande hotscenarier: +Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följande hotscenarier: Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) + Scenario: När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. + Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express + Scenario: Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. + Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) + Scenario (E): En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). Scenario (D): En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. + Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data + Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. - -2. Fyra säkerhetskrav formulerade i kravspecifikationen -För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: -· Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) -Formulering: Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. +2. Fyra säkerhetskrav formulerade i kravspecifikationen +För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: -· Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) -Formulering: Express-backenden ska validera och sanera (rensa) all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. +Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) +Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. +Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) +Express-backenden ska validera och sanera (rensa) all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. -· Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) -Formulering: Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. +Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) +Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. -· Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) -Formulering: Express-API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot överbelastning (Denial of Service) och automatiserade brute force-attacker. +Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) +Express-API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From b91d384d5e253d4a5d27d34c9f0e7817dd7a7220 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 15:05:09 +0200 Subject: [PATCH 12/46] requirements in bold --- planeringsfasen.md | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 2447d9b5..ab4eefdb 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -30,42 +30,43 @@ Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följande hotscenarier: -Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) +Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) -Scenario: När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. +Scenario: När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. -Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express +Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express -Scenario: Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. +Scenario:>/b> Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. -Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) +Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) -Scenario (E): En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). +Scenario (E): En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). -Scenario (D): En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. +Scenario (D): En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. -Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data +Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data + +Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. -Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. 2. Fyra säkerhetskrav formulerade i kravspecifikationen För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: -Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) +Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. -Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) -Express-backenden ska validera och sanera (rensa) all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. +Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) +Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. -Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) +Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. -Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) -Express-API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. +Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) +Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From 5b826bb648fc23d75eeeec1a29f261a4047d3ec3 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 15:08:21 +0200 Subject: [PATCH 13/46] Fix HTML tags and improve --- planeringsfasen.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index ab4eefdb..d9429e94 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -37,7 +37,7 @@ Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följan Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express -Scenario:>/b> Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. +Scenario: Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) @@ -68,5 +68,5 @@ Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. -Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) +Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From a9445f5870e8af788f386d3cb84326ea5d6b3a42 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 27 May 2026 15:15:28 +0200 Subject: [PATCH 14/46] Refine and remove Removed unnecessary explanations and streamlined security requirements section. --- planeringsfasen.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index d9429e94..1385957f 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -9,7 +9,6 @@ Express/Backend: 1 Databas: 5 Om tillitsgränserna: - Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. @@ -17,11 +16,9 @@ Användaren kan öppna Developer Tools och ändra i koden om de vill. Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. Pilarna (T & I): - De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. Kopplingen till våra säkerhetskrav: - Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker via krypterad HTTPS. Och eftersom vi vet att vi inte kan lita på Frontend-boxen (eftersom den ligger i den osäkra zonen), har vi lagt ett strikt säkerhetskrav på att Express/Backend måste göra all indatavalidering och behörighetskontroll innan något sparas i Databasen. @@ -52,21 +49,18 @@ Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följan Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. - 2. Fyra säkerhetskrav formulerade i kravspecifikationen + För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. - Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. - Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. - Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From 64acb07c7b0d85caf3b66d9ee03c49de64bcffbb Mon Sep 17 00:00:00 2001 From: satje-lab Date: Wed, 27 May 2026 15:35:55 +0200 Subject: [PATCH 15/46] =?UTF-8?q?Uppdaterad=20f=C3=B6r=20se=20om=20det=20f?= =?UTF-8?q?ungerar.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: nat316 Co-authored-by: HS-devs --- README.md | 5 ++++- planeringsfasen.md | 5 +---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index d6aeeb20..67f15683 100644 --- a/README.md +++ b/README.md @@ -1 +1,4 @@ -# yh-message-app-fullstack \ No newline at end of file +# yh-message-app-fullstack +Sarah Tjellander +Nathalie Loyd +Henrik Söderqvist \ No newline at end of file diff --git a/planeringsfasen.md b/planeringsfasen.md index 1385957f..df72ecd6 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,14 +1,11 @@ # Inlämning 1 - Planeringsfasen Browser: 0 - Frontend: 1 - Express/Backend: 1 - Databas: 5 -Om tillitsgränserna: +Om tillitsgränserna: Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. From ec27381a3daad601d9b4190b4deca8e5f096e712 Mon Sep 17 00:00:00 2001 From: HS-devs Date: Fri, 29 May 2026 10:13:46 +0200 Subject: [PATCH 16/46] Tester borttagna Co-authored-by: nat316 Co-authored-by: satj-lab --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 67f15683..407c6295 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,6 @@ # yh-message-app-fullstack Sarah Tjellander +Nu testar jag flödet + Nathalie Loyd Henrik Söderqvist \ No newline at end of file From d93a1e9ad0e7437fff31c49b5afcd6d35eb311ee Mon Sep 17 00:00:00 2001 From: HS-devs Date: Fri, 29 May 2026 10:17:40 +0200 Subject: [PATCH 17/46] hejhejtesttext --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 407c6295..b95a083b 100644 --- a/README.md +++ b/README.md @@ -3,4 +3,6 @@ Sarah Tjellander Nu testar jag flödet Nathalie Loyd +hejhejtesttest + Henrik Söderqvist \ No newline at end of file From ba14ecf0207174a85d56c283832b664dfba47103 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Mon, 1 Jun 2026 17:21:39 +0200 Subject: [PATCH 18/46] Formaterat dokumentet --- planeringsfasen.md | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index df72ecd6..8ebda33b 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,63 +1,66 @@ # Inlämning 1 - Planeringsfasen -Browser: 0 -Frontend: 1 -Express/Backend: 1 -Databas: 5 +Systemskiss **fet text** -Om tillitsgränserna: +- Browser: 0 +- Frontend: 1 +- Express/Backend: 1 +- Databas: 5 + +Hur vi har tänkt # Rubrik +Om tillitsgränserna: ### Liten rubrik Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. -Pilarna (T & I): +Pilarna (T & I): ### Liten rubrik De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. -Kopplingen till våra säkerhetskrav: +Kopplingen till våra säkerhetskrav: ### Liten rubrik Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker via krypterad HTTPS. Och eftersom vi vet att vi inte kan lita på Frontend-boxen (eftersom den ligger i den osäkra zonen), har vi lagt ett strikt säkerhetskrav på att Express/Backend måste göra all indatavalidering och behörighetskontroll innan något sparas i Databasen. -1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) +1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) ## Mellanstor rubrik Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följande hotscenarier: -Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) +- Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) ### Liten rubrik Scenario: När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. -Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express +- Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express ### Liten rubrik Scenario: Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. -Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) +- Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) ### Liten rubrik Scenario (E): En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). Scenario (D): En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. -Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data +- Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data ### Liten rubrik Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. -2. Fyra säkerhetskrav formulerade i kravspecifikationen +2. Fyra säkerhetskrav formulerade i kravspecifikationen ## Mellanstor rubrik För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: -Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) +- Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) ### Liten rubrik Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. -Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) +- Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) ### Liten rubrik Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. -Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) +- Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) ### Liten rubrik Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. -Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) +- Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) ### Liten rubrik Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From 73772415512c947c2ba5c2955846963a3cb83db3 Mon Sep 17 00:00:00 2001 From: sartje-lab Date: Mon, 1 Jun 2026 17:25:57 +0200 Subject: [PATCH 19/46] Kommentar i READ ME --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index b95a083b..dcbf16c4 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,7 @@ # yh-message-app-fullstack Sarah Tjellander Nu testar jag flödet +- Har testat formulera texten på inlämning FAS 1 enligt Markdown guide på Dicso Nathalie Loyd hejhejtesttest From b5c3b5cdb4770b88fc853a055d476ab02b82c389 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Mon, 1 Jun 2026 17:32:09 +0200 Subject: [PATCH 20/46] Kommenterat i READ ME --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index dcbf16c4..1b2ae964 100644 --- a/README.md +++ b/README.md @@ -3,6 +3,7 @@ Sarah Tjellander Nu testar jag flödet - Har testat formulera texten på inlämning FAS 1 enligt Markdown guide på Dicso + Nathalie Loyd hejhejtesttest From 8d9a4b4b662d9a5657cba532f14e1158bff7d27f Mon Sep 17 00:00:00 2001 From: satj-lab Date: Mon, 1 Jun 2026 17:52:50 +0200 Subject: [PATCH 21/46] =?UTF-8?q?Formaterat=20texten=20p=C3=A5=20FAS=201?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- planeringsfasen.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 8ebda33b..36531550 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -26,41 +26,40 @@ Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följande hotscenarier: - - Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) ### Liten rubrik - -Scenario: När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. + Scenario: **fet text** + När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. - Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express ### Liten rubrik - -Scenario: Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. + Scenario: **fet text** + Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. - Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) ### Liten rubrik + Scenario (E): **fet text** + En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). -Scenario (E): En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). - -Scenario (D): En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. + Scenario (D): **fet text** + En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. - Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data ### Liten rubrik - -Scenario: När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. + Scenario: **fet text** + När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. 2. Fyra säkerhetskrav formulerade i kravspecifikationen ## Mellanstor rubrik - -För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: + För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: - Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) ### Liten rubrik -Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. + Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. - Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) ### Liten rubrik -Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. + Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. - Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) ### Liten rubrik -Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. + Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. - Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) ### Liten rubrik -Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. + Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From be67bf634586e20dfc6b68adbbe41459b35d1a19 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Tue, 2 Jun 2026 10:58:06 +0200 Subject: [PATCH 22/46] =?UTF-8?q?=C3=84ndringar=20gjord=20under=20lektion?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- frontend/src/App.jsx | 7 ++++++- package-lock.json | 6 ++++++ 2 files changed, 12 insertions(+), 1 deletion(-) create mode 100644 package-lock.json diff --git a/frontend/src/App.jsx b/frontend/src/App.jsx index c668778f..e61b96dc 100644 --- a/frontend/src/App.jsx +++ b/frontend/src/App.jsx @@ -72,7 +72,12 @@ export const App = () => { /> )} {error &&

{error}

} - + Date: Tue, 2 Jun 2026 13:56:14 +0200 Subject: [PATCH 23/46] 2 juni, liveshare Co-authored-by: HS-devs Co-authored-by: satj-lab --- README.md | 6 +++++- backend/server.js | 7 +++++++ frontend/src/index.css | 3 ++- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 1b2ae964..b63a807d 100644 --- a/README.md +++ b/README.md @@ -7,4 +7,8 @@ Nu testar jag flödet Nathalie Loyd hejhejtesttest -Henrik Söderqvist \ No newline at end of file +Henrik Söderqvist + +Server.js app.delete rad 168-178 +Index.css OKad +Server.js app.get rad 126-137 diff --git a/backend/server.js b/backend/server.js index c8d0c218..1af580d4 100644 --- a/backend/server.js +++ b/backend/server.js @@ -136,6 +136,9 @@ app.get("/messages", async (req, res) => { } }) +//Rate Limiting för resursskydd, gäller Denial of Service (överbelastning) i STRIDE. +// Vi bör lägga till en blockering (en limiter) som stoppar en enskild användare från att göra för många anrop per minut. + app.post("/messages", authenticateUser, async (req, res) => { const message = new Message({ message: req.body.message, user: req.user._id }) try { @@ -177,6 +180,10 @@ app.delete("/messages/:id", async (req, res) => { } }) +//Strikt behörighetskontroll vid dataändring. Motverkar E (Elevation of Privilege) i STRIDE inom Express. +// Koden raderar meddelandet utan att kontrollera vem användaren är. +// Vi måste modifiera koden så att den jämför den inloggade användarens ID med meddelandets userId innan raderingen tillåts. + app.listen(PORT, () => { console.log(`Listening on port ${PORT}`) }) diff --git a/frontend/src/index.css b/frontend/src/index.css index 901556d8..186cfa44 100644 --- a/frontend/src/index.css +++ b/frontend/src/index.css @@ -1,4 +1,5 @@ -* { +// OK + * { font-family: "Courier New", Courier, monospace; box-sizing: border-box; } From d352f5b3ae52e452a2b1e93951055b1eb7c6394c Mon Sep 17 00:00:00 2001 From: satj-lab Date: Tue, 2 Jun 2026 17:57:42 +0200 Subject: [PATCH 24/46] Formatera planeringsfasen --- planeringsfasen.md | 62 +++++++++++++++++++++++++++++++--------------- 1 file changed, 42 insertions(+), 20 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 36531550..033ebb1e 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,65 +1,87 @@ # Inlämning 1 - Planeringsfasen -Systemskiss **fet text** +Systemskiss +**fet text** + +![alternativ text](file:///Users/sarahtjellander/Dropbox/Grupparbete/FAS%201/Systemskiss.png) - Browser: 0 - Frontend: 1 - Express/Backend: 1 - Databas: 5 -Hur vi har tänkt # Rubrik -Om tillitsgränserna: ### Liten rubrik +Hur vi har tänkt +# Rubrik +Om tillitsgränserna: +### Liten rubrik Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. -Pilarna (T & I): ### Liten rubrik +Pilarna (T & I): +### Liten rubrik De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. -Kopplingen till våra säkerhetskrav: ### Liten rubrik +Kopplingen till våra säkerhetskrav: +### Liten rubrik Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker via krypterad HTTPS. Och eftersom vi vet att vi inte kan lita på Frontend-boxen (eftersom den ligger i den osäkra zonen), har vi lagt ett strikt säkerhetskrav på att Express/Backend måste göra all indatavalidering och behörighetskontroll innan något sparas i Databasen. -1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) ## Mellanstor rubrik +1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) +## Mellanstor rubrik Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följande hotscenarier: -- Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) ### Liten rubrik - Scenario: **fet text** +- Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) +### Liten rubrik + Scenario: + **fet text** När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. -- Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express ### Liten rubrik - Scenario: **fet text** +- Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express +### Liten rubrik + Scenario: + **fet text** Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. -- Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) ### Liten rubrik - Scenario (E): **fet text** +- Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) +### Liten rubrik + Scenario (E): + **fet text** En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). - Scenario (D): **fet text** + Scenario (D): + **fet text** En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. -- Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data ### Liten rubrik - Scenario: **fet text** +- Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data +### Liten rubrik + Scenario: + **fet text** När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. -2. Fyra säkerhetskrav formulerade i kravspecifikationen ## Mellanstor rubrik +2. Fyra säkerhetskrav formulerade i kravspecifikationen +## Mellanstor rubrik För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: -- Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) ### Liten rubrik +- Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) +### Liten rubrik Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. -- Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) ### Liten rubrik +- Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) +### Liten rubrik Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. -- Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) ### Liten rubrik +- Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) +### Liten rubrik Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. -- Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) ### Liten rubrik +- Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) +### Liten rubrik Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From 5a16db942d1eb15b597a3636b83eeb8ae92949b4 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Tue, 2 Jun 2026 18:08:06 +0200 Subject: [PATCH 25/46] Formatera planeringsfasen --- planeringsfasen.md | 80 +++++++++++++++++----------------------------- 1 file changed, 30 insertions(+), 50 deletions(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 033ebb1e..03a27948 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -1,87 +1,67 @@ # Inlämning 1 - Planeringsfasen -Systemskiss -**fet text** - -![alternativ text](file:///Users/sarahtjellander/Dropbox/Grupparbete/FAS%201/Systemskiss.png) +**Systemskiss** - Browser: 0 - Frontend: 1 - Express/Backend: 1 - Databas: 5 -Hur vi har tänkt -# Rubrik -Om tillitsgränserna: -### Liten rubrik + +# Hur vi har tänkt + +### Om tillitsgränserna: Vi har delat upp systemet med två tydliga tillitsgränser. Allt till vänster, Browser/Frontend, körs på användarens egen enhet. Det betyder att det är en osäker miljö som vi inte kan kontrollera. Användaren kan öppna Developer Tools och ändra i koden om de vill. -Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna. - -Pilarna (T & I): -### Liten rubrik +Allt till höger, API-serven och Databasen, körs på vår egen server. Det är vår säkra miljö där vi sätter reglerna + +### Pilarna (T & I): De pilarna som går till höger representerar data som skickas in i systemet. Här har vi satt ett T (Tampering), eftersom det största hotet är att någon manipulerar datan på vägen (t.ex. ändrar i ett HTTP-anrop eller skickar med skadlig kod). De Tillitsgränspilarna till vänster är svaren som går tillbaka. Här har vi satt ett I (Information Disclosure), eftersom risken där är att vi råkar läcka ut känslig data i våra JSON-svar. - -Kopplingen till våra säkerhetskrav: -### Liten rubrik + +### Kopplingen till våra säkerhetskrav: Eftersom vi vet att pilarna hotas av T och I, krävs att all kommunikation sker via krypterad HTTPS. Och eftersom vi vet att vi inte kan lita på Frontend-boxen (eftersom den ligger i den osäkra zonen), har vi lagt ett strikt säkerhetskrav på att Express/Backend måste göra all indatavalidering och behörighetskontroll innan något sparas i Databasen. - -1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) -## Mellanstor rubrik + +## 1. Identifierade säkerhetsrisker och hotscenarier (Hotmodellering) Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följande hotscenarier: -- Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) -### Liten rubrik - Scenario: - **fet text** + +- ### Hot mot pilen "Öppnar" (T - Tampering): Nedladdning av skadlig kod (Man-in-the-Middle) + + **Scenario:** När en användare öppnar applikationen i sin Browser (0) och laddar ner Frontend (1 ESRD) över ett osäkert nätverk, kan en angripare avlyssna och manipulera (Tampering) källkoden. Angriparen byter ut er React-kod mot skadlig kod för att stjäla framtida inloggningsuppgifter. - -- Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express -### Liten rubrik - Scenario: - **fet text** + +- ### Hot mot pilen "HTTP-anrop" (T - Tampering): Injektionsattacker mot Express + **Scenario:** Eftersom data skickas från den osäkra användarmiljön, kan en elak användare manipulera ett HTTP-anrop och skicka med skadliga databasskript (t.ex. SQL-injektion) i meddelandefältet. Om Express skickar detta vidare till Databas (5 E) kan data raderas eller läckas. - -- Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) -### Liten rubrik - Scenario (E): - **fet text** +- ### Hot inuti boxen "Express/Backend & API" (ED - Elevation of Privilege & Denial of Service) + **Scenario (E):** En vanlig inloggad användare manipulerar ID-parametern i sitt HTTP-anrop (t.ex. ändrar meddelande-ID i URL:en) för att försöka redigera eller radera en annan användares meddelande, och lyckas därmed höja sina rättigheter (Elevation of Privilege). - - Scenario (D): - **fet text** + + **Scenario (D):** En angripare utnyttjar att API:et är publikt och bombarderar Express-boxen med miljontals automatiska HTTP-anrop (Denial of Service) så att servern överbelastas och kraschar för vanliga användare. - -- Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data -### Liten rubrik - Scenario: - **fet text** +- ### Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data + **Scenario:** När Express hämtar data från databasen för att skicka tillbaka ett svar, råkar API:et skicka med för mycket information i JSON-objektet (t.ex. lösenordshashar eller interna system-ID:n) som sedan exponeras i användarens Browser. -2. Fyra säkerhetskrav formulerade i kravspecifikationen -## Mellanstor rubrik +## 2. Fyra säkerhetskrav formulerade i kravspecifikationen För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: -- Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) -### Liten rubrik +- ### Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. -- Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) -### Liten rubrik +- ### Krav 2: Indatavalidering på serversidan (Motverkar T i HTTP-anrop) Express-backenden ska validera och rensa all indata från inkommande HTTP-anrop innan den bearbetas eller skickas vidare till Databasen, för att stoppa injektionsattacker och XSS. -- Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) -### Liten rubrik +- ### Krav 3: Strikt behörighetskontroll vid dataändring (Motverkar E i Express) Användaren ska i inloggat läge endast kunna redigera och radera sina egna meddelanden; Express-backenden måste verifiera att den autentiserade användarens ID matchar meddelandets ägar-ID innan ändringen godkänns i Databasen. -- Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) -### Liten rubrik +- ### Krav 4: Rate Limiting för resursskydd (Motverkar D i Express) Express/API:et ska begränsa antalet tillåtna HTTP-anrop per IP-adress (t.ex. max 100 anrop per minut) för att skydda applikationen mot DoS överbelastning och automatiserade brute force-attacker. From 8c995a1fe63b32577eef647fe5be2091bdea9349 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Tue, 2 Jun 2026 18:10:46 +0200 Subject: [PATCH 26/46] Formatera planeringsfasen --- planeringsfasen.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/planeringsfasen.md b/planeringsfasen.md index 03a27948..df12bd98 100644 --- a/planeringsfasen.md +++ b/planeringsfasen.md @@ -52,7 +52,8 @@ Utifrån från vår systemskiss och ESTRID-klassificeringen identifieras följan ## 2. Fyra säkerhetskrav formulerade i kravspecifikationen - För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: + +För att motverka de identifierade hoten ovan och säkra tillitsgränserna sätts följande krav: - ### Krav 1: Kryptering i rörelse (Motverkar T och I på dataflödena) Applikationen ska tvinga fram krypterad HTTPS-kommunikation för alla anrop och svar mellan Browser, Frontend och Express för att förhindra avlyssning och manipulering av data i rörelse. From d64d542a515febc1a283b88b87d9f12f754adca4 Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 3 Jun 2026 10:36:49 +0200 Subject: [PATCH 27/46] =?UTF-8?q?F=C3=B6reslagit=20en=20kod=C3=A4ndring=20?= =?UTF-8?q?p=C3=A5=20app.delete?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 4 +++- backend/server.js | 12 +++++++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b63a807d..913352b9 100644 --- a/README.md +++ b/README.md @@ -3,12 +3,14 @@ Sarah Tjellander Nu testar jag flödet - Har testat formulera texten på inlämning FAS 1 enligt Markdown guide på Dicso - Nathalie Loyd hejhejtesttest Henrik Söderqvist Server.js app.delete rad 168-178 +Jag har föreslagit en kodändring med förklaring. + Index.css OKad + Server.js app.get rad 126-137 diff --git a/backend/server.js b/backend/server.js index 1af580d4..485caf52 100644 --- a/backend/server.js +++ b/backend/server.js @@ -168,11 +168,21 @@ app.patch("/messages/:id", authenticateUser, async (req, res) => { } }) -app.delete("/messages/:id", async (req, res) => { +// 1. Vi lägger till "authenticateUser" här för att tvinga fram inloggning och få fram användarens ID +app.delete("/messages/:id", authenticateUser, async (req, res) => { if (!isValidId(req.params.id)) return res.status(400).json({ error: "Invalid message ID" }) try { const message = await Message.findById(req.params.id) if (!message) return res.status(404).json({ error: "Message not found" }) + +// 2. NY KONTROLL: Vi jämför meddelandets ägare med den inloggade användaren. + // Vi gör om ID till text (.toString()) för att datorn ska kunna jämföra dem korrekt. + if (message.user.toString() !== req.user.userId.toString()) { + // Om det INTE är samma person, stoppar vi anropet med felkod 403 (Förbjudet) + return res.status(403).json({ error: "You are not authorized to delete this message" }) + } + + // Hit kommer koden BARA om kontrollen ovan var godkänd await message.deleteOne() res.status(204).send() } catch (error) { From c0820ab056dcc0e2838eb0e9315c82680e16e8cd Mon Sep 17 00:00:00 2001 From: satj-lab Date: Wed, 3 Jun 2026 10:54:48 +0200 Subject: [PATCH 28/46] =?UTF-8?q?F=C3=B6reslagit=20en=20kod=C3=A4ndring=20?= =?UTF-8?q?p=C3=A5=20app.delete?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- backend/server.js | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/backend/server.js b/backend/server.js index 485caf52..ef0efc38 100644 --- a/backend/server.js +++ b/backend/server.js @@ -169,7 +169,7 @@ app.patch("/messages/:id", authenticateUser, async (req, res) => { }) // 1. Vi lägger till "authenticateUser" här för att tvinga fram inloggning och få fram användarens ID -app.delete("/messages/:id", authenticateUser, async (req, res) => { +app.delete("/messages/:id", async (req, res) => { if (!isValidId(req.params.id)) return res.status(400).json({ error: "Invalid message ID" }) try { const message = await Message.findById(req.params.id) @@ -177,9 +177,9 @@ app.delete("/messages/:id", authenticateUser, async (req, res) => { // 2. NY KONTROLL: Vi jämför meddelandets ägare med den inloggade användaren. // Vi gör om ID till text (.toString()) för att datorn ska kunna jämföra dem korrekt. - if (message.user.toString() !== req.user.userId.toString()) { - // Om det INTE är samma person, stoppar vi anropet med felkod 403 (Förbjudet) - return res.status(403).json({ error: "You are not authorized to delete this message" }) + // if (message.user.toString() !== req.user.userId.toString()) { + // // Om det INTE är samma person, stoppar vi anropet med felkod 403 (Förbjudet) + // return res.status(403).json({ error: "You are not authorized to delete this message" }) } // Hit kommer koden BARA om kontrollen ovan var godkänd From fe0ae4142ad310aa34ddffdeaac813ed555c11ff Mon Sep 17 00:00:00 2001 From: HS-devs Date: Wed, 3 Jun 2026 12:02:05 +0200 Subject: [PATCH 29/46] Lagt in kommentar om app.patch --- README.md | 2 ++ backend/server.js | 8 +++++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 913352b9..141f27aa 100644 --- a/README.md +++ b/README.md @@ -14,3 +14,5 @@ Jag har föreslagit en kodändring med förklaring. Index.css OKad Server.js app.get rad 126-137 + +seever.js app.patch rad 172 - 173 \ No newline at end of file diff --git a/backend/server.js b/backend/server.js index ef0efc38..6a85008a 100644 --- a/backend/server.js +++ b/backend/server.js @@ -139,6 +139,7 @@ app.get("/messages", async (req, res) => { //Rate Limiting för resursskydd, gäller Denial of Service (överbelastning) i STRIDE. // Vi bör lägga till en blockering (en limiter) som stoppar en enskild användare från att göra för många anrop per minut. + app.post("/messages", authenticateUser, async (req, res) => { const message = new Message({ message: req.body.message, user: req.user._id }) try { @@ -168,13 +169,17 @@ app.patch("/messages/:id", authenticateUser, async (req, res) => { } }) -// 1. Vi lägger till "authenticateUser" här för att tvinga fram inloggning och få fram användarens ID +// För att säkerställa att endast ägaren av ett meddelande kan redigera det, kontrollerade vi att i PATCH-routen för uppdatering av meddelanden. +// Detta fanns redan och den jämför den inloggade användarens ID (från JWT-token) med det userId som är kopplat till meddelandet i databasen. + + app.delete("/messages/:id", async (req, res) => { if (!isValidId(req.params.id)) return res.status(400).json({ error: "Invalid message ID" }) try { const message = await Message.findById(req.params.id) if (!message) return res.status(404).json({ error: "Message not found" }) +// 1. Vi lägger till "authenticateUser" här för att tvinga fram inloggning och få fram användarens ID // 2. NY KONTROLL: Vi jämför meddelandets ägare med den inloggade användaren. // Vi gör om ID till text (.toString()) för att datorn ska kunna jämföra dem korrekt. // if (message.user.toString() !== req.user.userId.toString()) { @@ -194,6 +199,7 @@ app.delete("/messages/:id", async (req, res) => { // Koden raderar meddelandet utan att kontrollera vem användaren är. // Vi måste modifiera koden så att den jämför den inloggade användarens ID med meddelandets userId innan raderingen tillåts. + app.listen(PORT, () => { console.log(`Listening on port ${PORT}`) }) From ca7cafc12a24cbda3ad67265dcecd1320d98accf Mon Sep 17 00:00:00 2001 From: "loyd.nathalie@gmail.com" <”nutzgames@gmail.com”> Date: Wed, 3 Jun 2026 15:22:05 +0200 Subject: [PATCH 30/46] Co-authored-by: satj-lab --- README.md | 6 +++++- backend/server.js | 19 +++++++++++++++++-- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 141f27aa..3f4c5dc8 100644 --- a/README.md +++ b/README.md @@ -15,4 +15,8 @@ Index.css OKad Server.js app.get rad 126-137 -seever.js app.patch rad 172 - 173 \ No newline at end of file +seever.js app.patch rad 172 - 173 +Server.js app.get rad 124-157 +Jag har föreslagt en kodändring med förklaring. + + diff --git a/backend/server.js b/backend/server.js index 6a85008a..ddd0120b 100644 --- a/backend/server.js +++ b/backend/server.js @@ -135,9 +135,24 @@ app.get("/messages", async (req, res) => { res.status(500).json({ message: "Could not fetch messages" }) } }) +//Rate Limiting för resursskydd, gäller Denial of Service (överbelastning) i STRIDE. En angripare kan skicka detta anrop 50 000 gånger i sekunden och krascha servern. +//Vi bör lägga till en blockering (en limiter) som stoppar en angripare från att göra för många anrop per minut. +//Vi föreslår att använda Rate Limiting-middleware (express-rate-limit) +//Node.js använder standardverktyget express-rate-limit för att lösa detta. Det läggs till högst upp i filen, och sedan appliceras det på endpoint. + +// 1. Importera verktyget för hastighetsbegränsning (detta görs över app.get) +// const rateLimit = require("express-rate-limit"); + +// 2. Definiera reglerna: Max 100 anrop per 15 minuter från samma IP (detta läggs under Const rateLimit) +// const messageLimiter = rateLimit({ +// windowMs: 15 * 60 * 1000, // 15 minuter i millisekunder +// max: 100, // Begränsa varje IP till 100 anrop per fönster +// message: { error: "Too many requests, please try again later." } +// }); + +// 3. Lägg till 'messageLimiter' som ett filter i din existerande app.get-kod +// app.get("/messages", messageLimiter, async (req, res) => { -//Rate Limiting för resursskydd, gäller Denial of Service (överbelastning) i STRIDE. -// Vi bör lägga till en blockering (en limiter) som stoppar en enskild användare från att göra för många anrop per minut. app.post("/messages", authenticateUser, async (req, res) => { From 8120e7e0dcbbab6efc76508c77d46058bc484258 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Wed, 3 Jun 2026 15:30:12 +0200 Subject: [PATCH 31/46] =?UTF-8?q?=C3=84ndringar=20i=20ReadMe?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 3f4c5dc8..5f383f0e 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,8 @@ # yh-message-app-fullstack Sarah Tjellander -Nu testar jag flödet - Har testat formulera texten på inlämning FAS 1 enligt Markdown guide på Dicso Nathalie Loyd -hejhejtesttest Henrik Söderqvist @@ -13,10 +11,9 @@ Jag har föreslagit en kodändring med förklaring. Index.css OKad -Server.js app.get rad 126-137 - -seever.js app.patch rad 172 - 173 Server.js app.get rad 124-157 Jag har föreslagt en kodändring med förklaring. +seever.js app.patch rad 172 - 173 + From 322b3fd1e4c6ec6465f7cfefdca59e15c05086b4 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Wed, 3 Jun 2026 15:37:38 +0200 Subject: [PATCH 32/46] =?UTF-8?q?=C3=84ndringar=20i=20ReadMe?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 5f383f0e..4c310ac8 100644 --- a/README.md +++ b/README.md @@ -7,13 +7,13 @@ Nathalie Loyd Henrik Söderqvist Server.js app.delete rad 168-178 -Jag har föreslagit en kodändring med förklaring. +- Jag har föreslagit en kodändring med förklaring. -Index.css OKad +Index.css +- OKad Server.js app.get rad 124-157 -Jag har föreslagt en kodändring med förklaring. - -seever.js app.patch rad 172 - 173 +- Jag har föreslagt en kodändring med förklaring. +Sever.js app.patch rad 172 - 173 From e93fad104aa61b359a66e97d7be2efc58b0b0ba7 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Wed, 3 Jun 2026 15:39:56 +0200 Subject: [PATCH 33/46] =?UTF-8?q?=C3=84ndringar=20under=20app.delete?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- backend/server.js | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/backend/server.js b/backend/server.js index ddd0120b..35b80a42 100644 --- a/backend/server.js +++ b/backend/server.js @@ -193,16 +193,9 @@ app.delete("/messages/:id", async (req, res) => { try { const message = await Message.findById(req.params.id) if (!message) return res.status(404).json({ error: "Message not found" }) - -// 1. Vi lägger till "authenticateUser" här för att tvinga fram inloggning och få fram användarens ID -// 2. NY KONTROLL: Vi jämför meddelandets ägare med den inloggade användaren. - // Vi gör om ID till text (.toString()) för att datorn ska kunna jämföra dem korrekt. - // if (message.user.toString() !== req.user.userId.toString()) { - // // Om det INTE är samma person, stoppar vi anropet med felkod 403 (Förbjudet) - // return res.status(403).json({ error: "You are not authorized to delete this message" }) } - // Hit kommer koden BARA om kontrollen ovan var godkänd + // Hit kommer koden BARA om kontrollen nedan var godkänd await message.deleteOne() res.status(204).send() } catch (error) { @@ -213,6 +206,12 @@ app.delete("/messages/:id", async (req, res) => { //Strikt behörighetskontroll vid dataändring. Motverkar E (Elevation of Privilege) i STRIDE inom Express. // Koden raderar meddelandet utan att kontrollera vem användaren är. // Vi måste modifiera koden så att den jämför den inloggade användarens ID med meddelandets userId innan raderingen tillåts. +// 1. Vi lägger till "authenticateUser" här för att tvinga fram inloggning och få fram användarens ID +// 2. NY KONTROLL: Vi jämför meddelandets ägare med den inloggade användaren. + // Vi gör om ID till text (.toString()) för att datorn ska kunna jämföra dem korrekt. + // if (message.user.toString() !== req.user.userId.toString()) { + // // Om det INTE är samma person, stoppar vi anropet med felkod 403 (Förbjudet) + // return res.status(403).json({ error: "You are not authorized to delete this message" }) app.listen(PORT, () => { From b82a7a7bcb828c4b9960cc02d3c49daca595580a Mon Sep 17 00:00:00 2001 From: satje-lab Date: Thu, 4 Jun 2026 23:29:45 +0200 Subject: [PATCH 34/46] =?UTF-8?q?Genomg=C3=A5ng=20av=20dokument=20efter=20?= =?UTF-8?q?risker?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 19 +++++++++-- backend/.env.example | 2 ++ backend/server.js | 47 +++++++++++++++++++++++++++ frontend/src/App.jsx | 5 +++ frontend/src/components/AuthModal.jsx | 4 +++ 5 files changed, 74 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 4c310ac8..cb4aa579 100644 --- a/README.md +++ b/README.md @@ -6,14 +6,27 @@ Nathalie Loyd Henrik Söderqvist -Server.js app.delete rad 168-178 +Server.js app.delete rad 238-251 - Jag har föreslagit en kodändring med förklaring. Index.css - OKad -Server.js app.get rad 124-157 +Server.js app.get rad 169-180 - Jag har föreslagt en kodändring med förklaring. -Sever.js app.patch rad 172 - 173 +Sever.js app.patch rad 211-228 +- Lagt till kommentar att meddelanden behöver valideras innan dem sparas i databasen. För undvika att skadlig kod skrivs in. + + +Backend .env.exemple +- dubbelkolla att http adressen endast används i utveckling .ent.exempel och inte i produktionskod. +- Inte hittat något, BASE_API använder https. + + +Server.js app.post rad 76-98 +- Risk: Information Disclosure och Brute Force. Krav: Rate Limiting + +Frontend src i alla .jsx - Lagt kommentar i App.jsx +- Klassiskt utvecklarmisstag. Ta bort: console.log helt och hållet. diff --git a/backend/.env.example b/backend/.env.example index d417a785..c1891042 100644 --- a/backend/.env.example +++ b/backend/.env.example @@ -2,3 +2,5 @@ PORT=3000 MONGO_URL=connection-string-from-mongodb-atlas JWT_SECRET=your-secret-here FRONTEND_URL=http://localhost:5500 + +# // FRONTEND_URL=http://localhost:5500 Det är en okrypterad adress och inte säker att använda. Är detta endast för utveckling? Säkerställ att det inte används i produktion. \ No newline at end of file diff --git a/backend/server.js b/backend/server.js index 35b80a42..113ce713 100644 --- a/backend/server.js +++ b/backend/server.js @@ -97,6 +97,49 @@ app.post("/login", async (req, res) => { }) } + //Dataläcka med felmeddelande. FRÅN FAS 1: Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data. + // Angriparen får reda på om användaren redan finns eller inte eftersom svaret är "Password is incorrect" eller "No account found with that username or email". + // För att undvika detta bör vi använda ett generellt felmeddelande som inte avslöjar vilken del av inloggningen som misslyckades. + // Givet val för angripare att använda Brute Force/Denail of Service (DoS) i STRIDE, där de kan försöka gissa lösenordet genom att göra många inloggningsförsök. + // Lägga till en Rate Limiter som en spärr specifikt för inloggningen (Krav 4 FRÅN FAS 1). Max 5 försök/15 min per IP-adress. + +//const rateLimit = require("express-rate-limit"); + +// 1. Skapa spärr: +// const loginLimiter = rateLimit({ +// windowMs: 15 * 60 * 1000, +// max: 5, +// message: { success: false, message: "Too many login attempts, please try again later." } +// }); + +// 2. APPLICERA SPÄRR: Lägg till 'loginLimiter' i endpointen +// app.post("/login", loginLimiter, async (req, res) => { +// try { +// const { login, password } = req.body +// const user = await User.findOne({ +// $or: [{ username: login }, { email: login }] +// }) + +// 3. MODIFIERAT FELMEDDELANDE 1: Säg inte att kontot saknas utan generellt meddelande: +// if (!user) { +// return res.status(401).json({ +// success: false, +// message: "Invalid username, email or password", +// response: null, +// }) +// } + +// const passwordMatch = await bcrypt.compare(password, user.password) + +// (!passwordMatch) { +// return res.status(401).json({ +// success: false, +// message: "Invalid username, email or password", +// response: null, +// }) +// } + + const accessToken = jwt.sign( { userId: user._id, username: user.username }, process.env.JWT_SECRET, @@ -187,6 +230,10 @@ app.patch("/messages/:id", authenticateUser, async (req, res) => { // För att säkerställa att endast ägaren av ett meddelande kan redigera det, kontrollerade vi att i PATCH-routen för uppdatering av meddelanden. // Detta fanns redan och den jämför den inloggade användarens ID (från JWT-token) med det userId som är kopplat till meddelandet i databasen. +// Dock saknas Krav 2 (Indatavalidering) FRÅN FAS 1 i både app.post och app.patch: +// Meddelanden valideras inte i båda endpoints. Via meddelanden kan en angripare skicka skadlig kod som sparas blint rakt in i databasen. +// Applikationen är helt öppen för XSS. Modifiera koden så meddelandet städas innan den skickas till databasen. + app.delete("/messages/:id", async (req, res) => { if (!isValidId(req.params.id)) return res.status(400).json({ error: "Invalid message ID" }) diff --git a/frontend/src/App.jsx b/frontend/src/App.jsx index e61b96dc..a0ce5f15 100644 --- a/frontend/src/App.jsx +++ b/frontend/src/App.jsx @@ -71,6 +71,11 @@ export const App = () => { }} /> )} + +//Kod körs direkt i användarens webbläsaren. Koden skriver ut hela objektet, inkl hemligt accessToken. Vem som helst kan öppna webbläsarens utvecklarverktyg och se det. +//Klassiskt misstag att logga känslig information i frontend. Ta bort console.log som skriver ut hela användarobjektet inklusive JWT-token. + + {error &&

{error}

} { } } +//Kod körs direkt i användarens webbläsaren. Koden skriver ut hela objektet, inkl hemligt accessToken. Vem som helst kan öppna webbläsarens utvecklarverktyg och se det. +//Klassiskt misstag att logga känslig information i frontend. Ta bort console.log, två rader. + + return (
Date: Fri, 5 Jun 2026 02:29:33 +0200 Subject: [PATCH 35/46] =?UTF-8?q?F=C3=B6rslag=20om=20=C3=A4ndring=20i=20b?= =?UTF-8?q?=C3=A5de=20front-=20och=20backend.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 5 +++++ backend/models/Message.js | 4 ++++ backend/server.js | 5 +++++ 3 files changed, 14 insertions(+) diff --git a/README.md b/README.md index 4c310ac8..a8ac7a4d 100644 --- a/README.md +++ b/README.md @@ -17,3 +17,8 @@ Server.js app.get rad 124-157 Sever.js app.patch rad 172 - 173 +Frontend - server.js: return res.status rad 100-103 +- Föreslagit ändring av felmeddelande för att minksa risken att någon kan se vilka konton som finns. + +Backend - models/Message.js: rad 18 - 20 +- Har lagt in förslag om att lägga in en begrännsning på längden av meddelandet. \ No newline at end of file diff --git a/backend/models/Message.js b/backend/models/Message.js index dbca0001..cb4e7f24 100644 --- a/backend/models/Message.js +++ b/backend/models/Message.js @@ -15,4 +15,8 @@ createdAt: { }, }) +// Skapa en begränsning på längden av meddelandet. +// Detta är en säkerhetsåtgärd för att förhindra att användare skickar mycket långa meddelanden, +// som i sin tur kan orsaka prestandaproblem eller överbelasta databasen. + export const Message = mongoose.model("Message", messageSchema) diff --git a/backend/server.js b/backend/server.js index 35b80a42..5cdb738b 100644 --- a/backend/server.js +++ b/backend/server.js @@ -97,6 +97,11 @@ app.post("/login", async (req, res) => { }) } + // Ändra felmeddelande för att inte avslöja om det var användarnamnet eller lösenordet som var felaktigt. + // Detta är en säkerhetsåtgärd för att förhindra att angripare får information om vilka användarnamn som finns i systemet. + // Vi returnerar samma felmeddelande oavsett om det var användarnamnet eller lösenordet som var fel. + // Exempel på ändrat felmeddelande: message: "Invalid login or password" + const accessToken = jwt.sign( { userId: user._id, username: user.username }, process.env.JWT_SECRET, From b44fa68fe7d16a78cd0223975e6fcacecca2815d Mon Sep 17 00:00:00 2001 From: satje-lab Date: Fri, 5 Jun 2026 09:14:31 +0200 Subject: [PATCH 36/46] Var ett dubbelproblem igen --- backend/server.js | 3 --- 1 file changed, 3 deletions(-) diff --git a/backend/server.js b/backend/server.js index 00a66d3f..14d7d5d4 100644 --- a/backend/server.js +++ b/backend/server.js @@ -97,12 +97,10 @@ app.post("/login", async (req, res) => { }) } -<<<<<<< HEAD // Ändra felmeddelande för att inte avslöja om det var användarnamnet eller lösenordet som var felaktigt. // Detta är en säkerhetsåtgärd för att förhindra att angripare får information om vilka användarnamn som finns i systemet. // Vi returnerar samma felmeddelande oavsett om det var användarnamnet eller lösenordet som var fel. // Exempel på ändrat felmeddelande: message: "Invalid login or password" -======= //Dataläcka med felmeddelande. FRÅN FAS 1: Hot mot pilen "JSON-svar" (I - Information Disclosure): Läckage av känslig data. // Angriparen får reda på om användaren redan finns eller inte eftersom svaret är "Password is incorrect" eller "No account found with that username or email". // För att undvika detta bör vi använda ett generellt felmeddelande som inte avslöjar vilken del av inloggningen som misslyckades. @@ -145,7 +143,6 @@ app.post("/login", async (req, res) => { // }) // } ->>>>>>> b82a7a7bcb828c4b9960cc02d3c49daca595580a const accessToken = jwt.sign( { userId: user._id, username: user.username }, From 28a32d447a3ef9c6bcbef4d729ca9abde0427c9a Mon Sep 17 00:00:00 2001 From: HS-devs Date: Thu, 11 Jun 2026 14:20:51 +0200 Subject: [PATCH 37/46] Flyttade textrad 244 i server.js --- backend/server.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backend/server.js b/backend/server.js index 14d7d5d4..46269334 100644 --- a/backend/server.js +++ b/backend/server.js @@ -246,7 +246,6 @@ app.delete("/messages/:id", async (req, res) => { if (!message) return res.status(404).json({ error: "Message not found" }) } - // Hit kommer koden BARA om kontrollen nedan var godkänd await message.deleteOne() res.status(204).send() } catch (error) { @@ -254,6 +253,7 @@ app.delete("/messages/:id", async (req, res) => { } }) +// Hit kommer koden BARA om kontrollen nedan var godkänd (flyttad text) //Strikt behörighetskontroll vid dataändring. Motverkar E (Elevation of Privilege) i STRIDE inom Express. // Koden raderar meddelandet utan att kontrollera vem användaren är. // Vi måste modifiera koden så att den jämför den inloggade användarens ID med meddelandets userId innan raderingen tillåts. From 4fe61993cba5bf530fbf651b7a9e9ab2e6a56b32 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Thu, 11 Jun 2026 17:07:57 +0200 Subject: [PATCH 38/46] =?UTF-8?q?Lagt=20till=20s=C3=A4kerhetsf=C3=B6rb?= =?UTF-8?q?=C3=A4ttringar=20f=C3=B6r=20inloggning?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 6 +++++- backend/server.js | 49 +++++++++++++++++++++++++++++++++++++---------- 2 files changed, 44 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 7dd6c859..5a16a83c 100644 --- a/README.md +++ b/README.md @@ -34,4 +34,8 @@ Frontend - server.js: return res.status rad 100-103 - Föreslagit ändring av felmeddelande för att minksa risken att någon kan se vilka konton som finns. Backend - models/Message.js: rad 18 - 20 -- Har lagt in förslag om att lägga in en begrännsning på längden av meddelandet. \ No newline at end of file +- Har lagt in förslag om att lägga in en begrännsning på längden av meddelandet. + +Server.js - app.post login +- SÄKERHETSFÖRBÄTTRING: Generellt felmeddelande för inloggning +- även lagt in ny kod som säkerhetsval \ No newline at end of file diff --git a/backend/server.js b/backend/server.js index 46269334..5138fe4a 100644 --- a/backend/server.js +++ b/backend/server.js @@ -80,23 +80,52 @@ app.post("/login", async (req, res) => { $or: [{ username: login }, { email: login }] }) - if (!user) { - return res.status(401).json({ - success: false, - message: "No account found with that username or email", - response: null, - }) - } + // 1. SKAPA EN DUMMY-HASH: Den används bara om användaren INTE hittas. + const dummyHash = "$2b$10$AzR7R.JvG7p0H2A9kYvOLeEa8yI1yZpE8fXfH1g7m7f8i9o0p1q2r" + + // 2. VÄLJ STRÄNG ATT JÄMFÖRA MED: Finns användaren? Ta dess riktiga hash. Finns den inte? Ta dummy-hashen. + const hashToCompare = user ? user.password : dummyHash - const passwordMatch = await bcrypt.compare(password, user.password) - if (!passwordMatch) { + // 3. KÖR BCRYPT: Detta tar alltid ~80-100ms och stoppar timing-attacker + const passwordMatch = await bcrypt.compare(password, hashToCompare) + + // 4. KONTROLLERA OM NÅGOT GICK FEL: + // Om användaren inte fanns ELLER om lösenordet inte matchade, skicka samma fel. + if (!user || !passwordMatch) { return res.status(401).json({ success: false, - message: "Password is incorrect", + message: "Invalid username/email or password", response: null, }) } + // 5. LYCKAD INLOGGNING: Hit kommer koden BARA om både användaren fanns OCH lösenordet var rätt! + const accessToken = jwt.sign( + { userId: user._id, username: user.username }, + process.env.JWT_SECRET, + { expiresIn: "2h" } + ) + + res.status(200).json({ + success: true, + message: "Login successful", + response: { + username: user.username, + id: user._id, + accessToken, + }, + }) + + } catch (error) { + res.status(500).json({ + success: false, + message: "Internal server error", + }) + } +}) + + + // SÄKERHETSFÖRBÄTTRING: Generellt felmeddelande för inloggning // Ändra felmeddelande för att inte avslöja om det var användarnamnet eller lösenordet som var felaktigt. // Detta är en säkerhetsåtgärd för att förhindra att angripare får information om vilka användarnamn som finns i systemet. // Vi returnerar samma felmeddelande oavsett om det var användarnamnet eller lösenordet som var fel. From 77550c9534e2ba923b6bf6e738a3e09773ae89a4 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Thu, 11 Jun 2026 17:34:28 +0200 Subject: [PATCH 39/46] =?UTF-8?q?Lagt=20till=20s=C3=A4kerhetsf=C3=B6rb?= =?UTF-8?q?=C3=A4ttringar=20f=C3=B6r=20inloggning?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- backend/server.js | 34 ++++++---------------------------- 1 file changed, 6 insertions(+), 28 deletions(-) diff --git a/backend/server.js b/backend/server.js index 5138fe4a..86af4260 100644 --- a/backend/server.js +++ b/backend/server.js @@ -99,27 +99,27 @@ app.post("/login", async (req, res) => { }) } - // 5. LYCKAD INLOGGNING: Hit kommer koden BARA om både användaren fanns OCH lösenordet var rätt! - const accessToken = jwt.sign( + // 5. LYCKAD INLOGGNING: Hit kommer man om både användaren fanns och lösenordet var rätt! + const accessToken = jwt.sign( { userId: user._id, username: user.username }, process.env.JWT_SECRET, { expiresIn: "2h" } ) - res.status(200).json({ + res.json({ success: true, - message: "Login successful", + message: "Logged in successfully", response: { username: user.username, id: user._id, accessToken, }, }) - } catch (error) { res.status(500).json({ success: false, - message: "Internal server error", + message: "Something went wrong", + error: error, }) } }) @@ -173,29 +173,7 @@ app.post("/login", async (req, res) => { // } - const accessToken = jwt.sign( - { userId: user._id, username: user.username }, - process.env.JWT_SECRET, - { expiresIn: "2h" } - ) - res.json({ - success: true, - message: "Logged in successfully", - response: { - username: user.username, - id: user._id, - accessToken, - }, - }) - } catch (error) { - res.status(500).json({ - success: false, - message: "Something went wrong", - error: error, - }) - } -}) const isValidId = (id) => mongoose.Types.ObjectId.isValid(id) From b56bbed8f5f444126bf0fa346244693cf7f0660c Mon Sep 17 00:00:00 2001 From: HS-devs Date: Fri, 12 Jun 2026 09:01:10 +0200 Subject: [PATCH 40/46] CodeQL --- .vscode/settings.json | 3 ++ .../codeql-pack.lock.yml | 30 +++++++++++++++++++ .../codeql-pack.yml | 7 +++++ codeql-custom-queries-javascript/example.ql | 12 ++++++++ 4 files changed, 52 insertions(+) create mode 100644 .vscode/settings.json create mode 100644 codeql-custom-queries-javascript/codeql-pack.lock.yml create mode 100644 codeql-custom-queries-javascript/codeql-pack.yml create mode 100644 codeql-custom-queries-javascript/example.ql diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 00000000..6cefa7f7 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "codeQL.createQuery.qlPackLocation": "c:\\Users\\enriq\\OneDrive\\Skrivbord\\School\\yh-message-app-fullstack" +} \ No newline at end of file diff --git a/codeql-custom-queries-javascript/codeql-pack.lock.yml b/codeql-custom-queries-javascript/codeql-pack.lock.yml new file mode 100644 index 00000000..fd2051e9 --- /dev/null +++ b/codeql-custom-queries-javascript/codeql-pack.lock.yml @@ -0,0 +1,30 @@ +--- +lockVersion: 1.0.0 +dependencies: + codeql/concepts: + version: 0.0.25 + codeql/controlflow: + version: 2.0.35 + codeql/dataflow: + version: 2.1.7 + codeql/javascript-all: + version: 2.7.2 + codeql/mad: + version: 1.0.51 + codeql/regex: + version: 1.0.51 + codeql/ssa: + version: 2.0.27 + codeql/threat-models: + version: 1.0.51 + codeql/tutorial: + version: 1.0.51 + codeql/typetracking: + version: 2.0.35 + codeql/util: + version: 2.0.38 + codeql/xml: + version: 1.0.51 + codeql/yaml: + version: 1.0.51 +compiled: false diff --git a/codeql-custom-queries-javascript/codeql-pack.yml b/codeql-custom-queries-javascript/codeql-pack.yml new file mode 100644 index 00000000..1c5c8b31 --- /dev/null +++ b/codeql-custom-queries-javascript/codeql-pack.yml @@ -0,0 +1,7 @@ +--- +library: false +warnOnImplicitThis: false +name: getting-started/codeql-extra-queries-javascript +version: 1.0.0 +dependencies: + codeql/javascript-all: ^2.7.2 diff --git a/codeql-custom-queries-javascript/example.ql b/codeql-custom-queries-javascript/example.ql new file mode 100644 index 00000000..c9770d9c --- /dev/null +++ b/codeql-custom-queries-javascript/example.ql @@ -0,0 +1,12 @@ +/** + * This is an automatically generated file + * @name Hello world + * @kind problem + * @problem.severity warning + * @id javascript/example/hello-world + */ + +import javascript + +from File f +select f, "Hello, world!" \ No newline at end of file From d13576dbf96b2c3008a64267b1f5c4ee922c8dcf Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Fri, 12 Jun 2026 09:15:32 +0200 Subject: [PATCH 41/46] Add CodeQL analysis workflow configuration --- .github/workflows/codeql.yml | 99 ++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 .github/workflows/codeql.yml diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml new file mode 100644 index 00000000..654bfd34 --- /dev/null +++ b/.github/workflows/codeql.yml @@ -0,0 +1,99 @@ +# For most projects, this workflow file will not need changing; you simply need +# to commit it to your repository. +# +# You may wish to alter this file to override the set of languages analyzed, +# or to provide custom queries or build logic. +# +# ******** NOTE ******** +# We have attempted to detect the languages in your repository. Please check +# the `language` matrix defined below to confirm you have the correct set of +# supported CodeQL languages. +# +name: "CodeQL Advanced" + +on: + push: + branches: [ "main" ] + pull_request: + branches: [ "main" ] + schedule: + - cron: '30 17 * * 4' + +jobs: + analyze: + name: Analyze (${{ matrix.language }}) + # Runner size impacts CodeQL analysis time. To learn more, please see: + # - https://gh.io/recommended-hardware-resources-for-running-codeql + # - https://gh.io/supported-runners-and-hardware-resources + # - https://gh.io/using-larger-runners (GitHub.com only) + # Consider using larger runners or machines with greater resources for possible analysis time improvements. + runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }} + permissions: + # required for all workflows + security-events: write + + # required to fetch internal or private CodeQL packs + packages: read + + # only required for workflows in private repositories + actions: read + contents: read + + strategy: + fail-fast: false + matrix: + include: + - language: javascript-typescript + build-mode: none + # CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift' + # Use `c-cpp` to analyze code written in C, C++ or both + # Use 'java-kotlin' to analyze code written in Java, Kotlin or both + # Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both + # To learn more about changing the languages that are analyzed or customizing the build mode for your analysis, + # see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning. + # If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how + # your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages + steps: + - name: Checkout repository + uses: actions/checkout@v4 + + # Add any setup steps before running the `github/codeql-action/init` action. + # This includes steps like installing compilers or runtimes (`actions/setup-node` + # or others). This is typically only required for manual builds. + # - name: Setup runtime (example) + # uses: actions/setup-example@v1 + + # Initializes the CodeQL tools for scanning. + - name: Initialize CodeQL + uses: github/codeql-action/init@v4 + with: + languages: ${{ matrix.language }} + build-mode: ${{ matrix.build-mode }} + # If you wish to specify custom queries, you can do so here or in a config file. + # By default, queries listed here will override any specified in a config file. + # Prefix the list here with "+" to use these queries and those in the config file. + + # For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs + # queries: security-extended,security-and-quality + + # If the analyze step fails for one of the languages you are analyzing with + # "We were unable to automatically build your code", modify the matrix above + # to set the build mode to "manual" for that language. Then modify this step + # to build your code. + # ℹ️ Command-line programs to run using the OS shell. + # 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun + - name: Run manual build steps + if: matrix.build-mode == 'manual' + shell: bash + run: | + echo 'If you are using a "manual" build mode for one or more of the' \ + 'languages you are analyzing, replace this with the commands to build' \ + 'your code, for example:' + echo ' make bootstrap' + echo ' make release' + exit 1 + + - name: Perform CodeQL Analysis + uses: github/codeql-action/analyze@v4 + with: + category: "/language:${{matrix.language}}" From 7c6722114c1f1a1a54653daaffd5eef1bbd8dcb2 Mon Sep 17 00:00:00 2001 From: HS-devs Date: Fri, 12 Jun 2026 09:28:46 +0200 Subject: [PATCH 42/46] =?UTF-8?q?Tog=20bort=20m=C3=A5sbracket=20fr=C3=A5n?= =?UTF-8?q?=20rad=20254=20server.js?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- backend/server.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backend/server.js b/backend/server.js index 86af4260..47c6b64c 100644 --- a/backend/server.js +++ b/backend/server.js @@ -251,7 +251,7 @@ app.delete("/messages/:id", async (req, res) => { try { const message = await Message.findById(req.params.id) if (!message) return res.status(404).json({ error: "Message not found" }) - } + await message.deleteOne() res.status(204).send() From 418669daffbefccbb105cac405d7e388a1341e81 Mon Sep 17 00:00:00 2001 From: HS-devs Date: Fri, 12 Jun 2026 10:54:08 +0200 Subject: [PATCH 43/46] console.log --- frontend/src/App.jsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/frontend/src/App.jsx b/frontend/src/App.jsx index a0ce5f15..ca8e00b3 100644 --- a/frontend/src/App.jsx +++ b/frontend/src/App.jsx @@ -65,7 +65,7 @@ export const App = () => { mode={modal} onClose={() => setModal(null)} onSuccess={(data) => { - console.log("User logged in:", data) + // console.log("User logged in:", data) setUser(data) setModal(null) }} From f30bea3b41769cf79a886e5794ac79432b84c5de Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Fri, 12 Jun 2026 17:33:03 +0200 Subject: [PATCH 44/46] Granskningsrapport fas 3 --- granskningsfasen.md | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/granskningsfasen.md b/granskningsfasen.md index 088f9718..7d394238 100644 --- a/granskningsfasen.md +++ b/granskningsfasen.md @@ -1 +1,29 @@ -# Inlämning 3 - Granskningsfasen \ No newline at end of file +# Inlämning 3 - Granskningsfasen + +Granskningsrapport – Fas 3 + +I granskningen har vi gått igenom applikationen utifrån de säkerhetskrav som sattes i +fas 1. Fokus har legat på kommunikationen mellan frontend och backend, hantering av användarinloggning, behörighetskontroll och skydd mot för många anrop. + +De verktyg som har varit mest relevanta för projektet är CodeQL och Dependabot. CodeQL används för att hitta riskabla kodmönster, medan Dependabot används för att upptäcka sårbara eller gamla dependencies. +Utöver verktygen har vi även gjort en manuell granskning och tagit hjälp av andra LLM:er, eftersom vissa brister såsom console.log inte alltid upptäcks automatiskt. + +En av de tydligaste säkerhetsbristerna är att backend behöver vara den plats där behörighet kontrolleras, det vill säga vilken som har behörighet att radera meddelande i appen. +Frontend kan dölja knappar och styra användarflödet, men det räcker inte som säkerhet. +En användare kan alltid skicka anrop direkt mot API:t. +Därför bör routes som ändrar eller raderar data alltid kräva autentisering och kontrollera att användaren äger den data som ändras. +Detta kopplas till OWASP: Broken Access Control. + +Vi identifierade även att login-flödet bör skyddas bättre. Felmeddelanden vid misslyckad inloggning bör vara generiska, så att systemet inte avslöjar om användarnamnet eller lösenordet var fel. +Dessutom bör rate limiting införas på login och andra känsliga routes för att minska risken för brute force och DoS-liknande belastning vilket vi kan koppla till +OWASP: Identification and Authentication Failures, eftersom det handlar om att stärka autentiseringsflödet och skydda inloggningen från missbruk. + +I frontend bör loggar som skriver ut användardata eller access token tas bort. +Sådana loggar kan vara användbara under utveckling, men i färdig kod innebär de en onödig risk för informationsläckage. + +Sammanfattningsvis bedömer vi att applikationen har en fungerande säkerhetsgrund, men att några viktiga förbättringar behövs. +De viktigaste åtgärderna är att stärka behörighetskontrollen i backend, lägga till tydligare server-side validering, införa rate limiting och ta bort onödiga loggar av känslig information. + +Vidare så inser vi också vikten av att inte lita fullt ut på AI-verktyg, och att korsreferera information såsom problem och lösningar. +Men även vara uppmärksam även om det inte flaggas för några problem, kan vara att just det verktyget inte flaggar för det specifika problemet. +Därför är det viktigt att inte förlita sig ett specifikt verktyg, och om möjligheten finns, göra manuella tester och be kollegor om stöd. From ea1512f8164d756b36578953445a20f17eaf8df0 Mon Sep 17 00:00:00 2001 From: HS-devs <56208822+HS-devs@users.noreply.github.com> Date: Fri, 12 Jun 2026 17:35:56 +0200 Subject: [PATCH 45/46] Refine security issue description in granskningsfasen.md Clarified the explanation of backend permission checks and improved wording for better readability. --- granskningsfasen.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/granskningsfasen.md b/granskningsfasen.md index 7d394238..deb1ac3a 100644 --- a/granskningsfasen.md +++ b/granskningsfasen.md @@ -8,7 +8,7 @@ fas 1. Fokus har legat på kommunikationen mellan frontend och backend, hanterin De verktyg som har varit mest relevanta för projektet är CodeQL och Dependabot. CodeQL används för att hitta riskabla kodmönster, medan Dependabot används för att upptäcka sårbara eller gamla dependencies. Utöver verktygen har vi även gjort en manuell granskning och tagit hjälp av andra LLM:er, eftersom vissa brister såsom console.log inte alltid upptäcks automatiskt. -En av de tydligaste säkerhetsbristerna är att backend behöver vara den plats där behörighet kontrolleras, det vill säga vilken som har behörighet att radera meddelande i appen. +En av de tydligaste säkerhetsbristerna är att backend behöver vara den plats där behörighet kontrolleras, till exempel vem som har behörighet att radera meddelanden i appen. Frontend kan dölja knappar och styra användarflödet, men det räcker inte som säkerhet. En användare kan alltid skicka anrop direkt mot API:t. Därför bör routes som ändrar eller raderar data alltid kräva autentisering och kontrollera att användaren äger den data som ändras. From a6adb5918e65552320e22e9ddfa0308cd3320ac6 Mon Sep 17 00:00:00 2001 From: satje-lab Date: Sun, 14 Jun 2026 15:00:21 +0200 Subject: [PATCH 46/46] Formatering. i granskningsfasen.md --- granskningsfasen.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/granskningsfasen.md b/granskningsfasen.md index deb1ac3a..c516a123 100644 --- a/granskningsfasen.md +++ b/granskningsfasen.md @@ -1,6 +1,6 @@ # Inlämning 3 - Granskningsfasen -Granskningsrapport – Fas 3 +### Granskningsrapport – Fas 3 I granskningen har vi gått igenom applikationen utifrån de säkerhetskrav som sattes i fas 1. Fokus har legat på kommunikationen mellan frontend och backend, hantering av användarinloggning, behörighetskontroll och skydd mot för många anrop. @@ -12,11 +12,11 @@ En av de tydligaste säkerhetsbristerna är att backend behöver vara den plats Frontend kan dölja knappar och styra användarflödet, men det räcker inte som säkerhet. En användare kan alltid skicka anrop direkt mot API:t. Därför bör routes som ändrar eller raderar data alltid kräva autentisering och kontrollera att användaren äger den data som ändras. -Detta kopplas till OWASP: Broken Access Control. +Detta kopplas till OWASP: *Broken Access Control*. Vi identifierade även att login-flödet bör skyddas bättre. Felmeddelanden vid misslyckad inloggning bör vara generiska, så att systemet inte avslöjar om användarnamnet eller lösenordet var fel. Dessutom bör rate limiting införas på login och andra känsliga routes för att minska risken för brute force och DoS-liknande belastning vilket vi kan koppla till -OWASP: Identification and Authentication Failures, eftersom det handlar om att stärka autentiseringsflödet och skydda inloggningen från missbruk. +OWASP: *Identification and Authentication Failures*, eftersom det handlar om att stärka autentiseringsflödet och skydda inloggningen från missbruk. I frontend bör loggar som skriver ut användardata eller access token tas bort. Sådana loggar kan vara användbara under utveckling, men i färdig kod innebär de en onödig risk för informationsläckage.