01 - 10 najlepszych OWASP 2025: Przewodnik dla programistów
Każda linia kodu, którą piszemy, niesie ze sobą ukrytą odpowiedzialność: ochronę danych i zaufanie użytkowników. W 2025 roku, wraz z coraz bardziej złożonymi aplikacjami, architekturami rozproszone i rosnące wykorzystanie narzędzi do automatycznego generowania kodu, Bezpieczeństwo nie może być już kwestią drugorzędną. Tam OWASP Top 10 2025 reprezentuje zaktualizowane zestawienie dziesięciu najbardziej krytycznych luk w aplikacjach internetowych i wszystkich programista powinien to dokładnie wiedzieć.
W tym przewodniku przeanalizowano wszystkie dziesięć kategorii nowej listy, ze szczególnym uwzględnieniem dwie nowe kategorie wprowadzone w 2025 r: Awarie łańcucha dostaw oprogramowania (A03) e Niewłaściwe postępowanie w wyjątkowych warunkach (A10). Dla każdej luki znajdziesz jasne wyjaśnienia, wrażliwy i bezpieczny kod w TypeScript/Node.js i konkretne najlepsze praktyki dla Angulara.
Czego się nauczysz
- Wszystkie 10 kategorii OWASP 2025, w tym 2 nowe
- Główne różnice w porównaniu do wersji 2021
- Przykłady podatnego kodu i powiązanych środków zaradczych
- Jak zabezpieczyć łańcuch dostaw zależności npm
- dlaczego 45% kodu generowanego przez sztuczną inteligencję nie przechodzi testów bezpieczeństwa
- Specyficzna dla Angulara lista kontrolna służąca zabezpieczeniu aplikacji
Czym jest OWASP i jak narodziło się Top 10
La Otwarty ogólnoświatowy projekt bezpieczeństwa aplikacji (OWASP) i fundament organizacja non-profit założona w 2001 roku w celu poprawy bezpieczeństwa oprogramowania na poziomie globalnym globalny. Jego najbardziej znanym projektem jest OWASP Top 10: dokument zaktualizowano odnośnik zawierający listę dziesięciu najbardziej krytycznych luk w aplikacjach internetowych okresowo w oparciu o rzeczywiste dane zebrane od setek organizacji.
Lista jest tworzona na podstawie analizy milionów i setek tysięcy aplikacji podatność. Proces łączy dane empiryczne (prawdziwe wypadki, relacje wg bezpieczeństwo, automatyczna analiza) za pomocą a ankieta społeczna to zbiera obawy ekspertów ds. bezpieczeństwa dotyczące pojawiających się zagrożeń. Mapa każdej kategorii jeden lub więcej CWE (wyliczenie typowych słabych stron)lub standardowe klasyfikacje słabości oprogramowania.
Poprzednie wersje
Lista OWASP Top 10 miała kilka edycji: 2004, 2007, 2010, 2013, 2017, 2021 i obecnie 2025. Każda aktualizacja odzwierciedla ewolucję zagrożeń. W 2017 roku na pierwszym miejscu znalazły się Zastrzyki miejsce; w 2021 r. przewyższyła je zepsuta kontrola dostępu. W 2025 roku widzimy zmiany jeszcze bardziej znaczące, wraz z wejściem dwóch zupełnie nowych kategorii, które odzwierciedlają współczesne wyzwania związane z tworzeniem oprogramowania.
Co nowego w OWASP Top 10 2025
Edycja 2025 przynosi istotne zmiany w stosunku do 2021. Oto pełna lista zmiany pozycji:
| Pozycja | OWASP 2025 | Zmiana od 2021 roku |
|---|---|---|
| A01 | Zepsuta kontrola dostępu | Potwierdzono na pierwszym miejscu (było A01:2021). Teraz zawiera SSRF |
| A02 | Błędna konfiguracja zabezpieczeń | Awansuje z numeru 5 na numer 2 |
| A03 | Awarie łańcucha dostaw oprogramowania | NOWOŚĆ – rozszerzenie A06:2021 (Komponenty podatne na ataki) |
| A04 | Awarie kryptograficzne | Spada z #2 na #4 |
| A05 | Zastrzyk | Spada z #3 na #5 |
| A06 | Niebezpieczny projekt | Spada z #4 na #6 |
| A07 | Błędy uwierzytelniania | Potwierdzone w punkcie 7 |
| A08 | Awarie oprogramowania lub integralności danych | Potwierdzone w punkcie 8 |
| A09 | Rejestrowanie zabezpieczeń i alarmowanie o błędach | Potwierdzono pod numerem 9 (przemianowano na „Alerty” zamiast „Monitorowanie”) |
| A10 | Niewłaściwe postępowanie w wyjątkowych warunkach | NOWOŚĆ - zastępuje SSRF (teraz włączony do A01) |
Dwie kluczowe zmiany
A03: Awarie łańcucha dostaw oprogramowania - Ataki na łańcuch dostaw oprogramowania eksplodowało w ostatnich latach. Ta kategoria została uznana za głównym problemem w ankiecie społeczności OWASP. Obejmuje literówkę, zamieszanie w zależnościach, złośliwe pakiety i zagrożone potoki CI/CD.
A10: Niewłaściwe postępowanie w wyjątkowych warunkach - Niewłaściwe zarządzanie błędów i wyjątków i obecnie jest uznawany za autonomiczny wektor ataku. Zawiera 24 CWE związane z nieodpowiednią obsługą błędów, otwieraniem się w przypadku awarii i wyciekami wrażliwych informacji poprzez komunikaty o błędach.
A01:2025 - Zepsuta kontrola dostępu
Il Zepsuta kontrola dostępu czwarty rok utrzymuje się na pierwszym miejscu kolejny. Występuje, gdy użytkownik może uzyskać dostęp do zasobów lub wykonać akcje do którego nie ma uprawnień. Do najpopularniejszych form należą: IDOR (Niebezpieczne bezpośrednie odniesienie do obiektu), przejście ścieżki, obejście sterowania role i manipulowanie tokenami lub parametrami adresu URL.
W 2025 roku kategoria ta ma włączył SSRF (Fałszowanie żądań po stronie serwera), który w wersji 2021 zajmował pozycję A10. Logika jest taka, że SSRF reprezentuje zasadniczo awaria kontroli dostępu: serwer wysyła żądania do zasobów, do których nie powinna sięgać.
Przykład: IDOR (niebezpieczne bezpośrednie odniesienie do obiektu)
// VULNERABILE: nessun controllo di ownership
app.get('/api/users/:id/profile', async (req, res) => {
// Chiunque può vedere il profilo di qualsiasi utente cambiando l'ID
const user = await User.findById(req.params.id);
res.json(user);
});
// SICURO: verifica ownership + ruolo
app.get('/api/users/:id/profile', authenticate, async (req, res) => {
if (req.user.id !== req.params.id && req.user.role !== 'admin') {
return res.status(403).json({ error: 'Accesso non autorizzato' });
}
const user = await User.findById(req.params.id);
if (!user) {
return res.status(404).json({ error: 'Utente non trovato' });
}
res.json(user);
});
Przykład: przemierzanie ścieżki
import path from 'path';
// VULNERABILE: l'utente controlla il percorso del file
app.get('/api/files/:filename', (req, res) => {
// Un attaccante può richiedere: ../../../etc/passwd
res.sendFile(`/uploads/${req.params.filename}`);
});
// SICURO: normalizza e valida il percorso
const UPLOAD_DIR = '/var/www/uploads';
app.get('/api/files/:filename', authenticate, (req, res) => {
const filename = path.basename(req.params.filename);
const filePath = path.join(UPLOAD_DIR, filename);
// Verifica che il percorso risolto sia dentro UPLOAD_DIR
if (!filePath.startsWith(UPLOAD_DIR)) {
return res.status(400).json({ error: 'Percorso non valido' });
}
res.sendFile(filePath);
});
Obrona kątowa dla uszkodzonej kontroli dostępu
- Narzędzie Strażnicy Trasy (
canActivate,canMatch) w celu ochrony zarezerwowanych tras - Użyj Przechwytywacz HTTP aby automatycznie dołączać token JWT do każdego żądania
- Ukryj elementy interfejsu użytkownika w oparciu o uprawnienia, ale zawsze ważne po stronie serwera
- Nigdy nie wstawiaj ról ani uprawnień do localStorage bez sprawdzenia po stronie zaplecza
- Scentralizuj logikę autoryzacji w jednym Usługa autoryzacji wielokrotnego użytku
A02:2025 — Błędna konfiguracja zabezpieczeń
Le Błędna konfiguracja zabezpieczeń w 2025 r. awansują z 5. na 2. miejsce. Ten skok odzwierciedla prawdziwy fakt: wraz ze wzrostem złożoności konfiguracji (chmura, kontenery, mikroserwisy, CDN) błędy konfiguracyjne stały się jednym z najczęstszych przyczyn naruszeń.
Do tej kategorii zaliczają się: niezmienione konfiguracje domyślne, bezpieczne nagłówki HTTP brak, CORS zbyt liberalny, ślady stosu ujawnione w produkcji, porty i usługi nie niezbędne odsłonięte, a funkcje debugowania pozostawione aktywne.
Nagłówek zabezpieczeń i CORS
import helmet from 'helmet';
import cors from 'cors';
const app = express();
// Header di sicurezza con Helmet
app.use(helmet({
contentSecurityPolicy: {
directives: {
defaultSrc: ["'self'"],
scriptSrc: ["'self'"],
styleSrc: ["'self'", "https://fonts.googleapis.com"],
imgSrc: ["'self'", "data:", "https:"],
fontSrc: ["'self'", "https://fonts.gstatic.com"],
connectSrc: ["'self'", "https://api.tuodominio.com"],
frameAncestors: ["'none'"], // Protegge da clickjacking
objectSrc: ["'none'"],
}
},
referrerPolicy: { policy: 'strict-origin-when-cross-origin' },
hsts: { maxAge: 31536000, includeSubDomains: true, preload: true },
}));
// CORS restrittivo
app.use(cors({
origin: ['https://tuodominio.com'],
methods: ['GET', 'POST', 'PUT', 'DELETE'],
allowedHeaders: ['Content-Type', 'Authorization'],
credentials: true,
maxAge: 86400 // Cache preflight per 24 ore
}));
Typowe błędy konfiguracyjne
Access-Control-Allow-Origin: *w produkcji- Ślady pełnego stosu widoczne w odpowiedziach na błędy
- Domyślne dane uwierzytelniające niezmienione (admin/admin)
- Porty debugowania (9229 dla Node.js) udostępnione w środowisku produkcyjnym
- Plik
.envpublicznie dostępne - Lista katalogów włączona na serwerze internetowym
A03:2025 — Awarie łańcucha dostaw oprogramowania (NOWOŚĆ)
To jedna z najważniejszych nowości w rankingu OWASP Top 10 2025. Kategoria Awarie łańcucha dostaw oprogramowania rozszerza poprzedni A06:2021 (Vulnerable i przestarzałe komponenty), aby objąć znacznie szerszy zakres: nie tylko zależności podatny na zagrożenia, ale cały ekosystem tworzenia, dystrybucji i aktualizacji oprogramowania.
W 2025 r. w tej kategorii odnotowano najwyższy średni współczynnik zapadalności (5,19%) we wszystkich kategoriach podczas testów. Uznano to również za kwestię budzącą największe obawy w ankiecie społeczności OWASP, według której biorą pod uwagę eksperci ds. bezpieczeństwa ataki na łańcuch dostaw jako najszybciej rosnące zagrożenie.
Rodzaje ataku na łańcuch dostaw
Ataki na łańcuch dostaw oprogramowania przybierają różne formy różne cechy i poziomy zaawansowania:
- Literowanie: Złośliwe pakiety o nazwach podobnych do popularnych bibliotek (np.
lodahszamiastlodash,expreszamiastexpress) - Zamieszanie zależności: zamiast legalnego instalowany jest pakiet publiczny o tej samej nazwie co pakiet wewnętrzny
- Przejęcie konta: narażanie kont opiekunów w celu wstrzyknięcia złośliwego kodu do legalnych pakietów
- Zbuduj zatrucie rurociągu: wstrzykiwanie złośliwego kodu do potoku CI/CD podczas procesu kompilacji
- Slopsquat: pakiety wykorzystujące nazwy zależności wymyślone przez sztuczną inteligencję (halucynacje) jako cele ataku
Prawdziwy wypadek: wrzesień 2025 r
We wrześniu 2025 r. kampania phishingowa włamała się na konta opiekunów npm, co doprowadziło do naruszenia co najmniej 27 pakietów z miliardami pobrań tygodniowo. Samoreplikujący się robak o nazwie Shai-Hulud zainfekował ponad 500 pakietów przed neutralizacją. Ten incydent pokazuje, jak ważna jest ochrona łańcucha dostaw.
Praktyczne zabezpieczenia łańcucha dostaw
# 1. Usa npm ci (non npm install) per rispettare il lockfile
npm ci
# 2. Audit delle vulnerabilità in CI/CD
npm audit --audit-level=high
# 3. Verifica le firme dei pacchetti (npm 9+)
npm audit signatures
# 4. Blocca i registry non autorizzati in .npmrc
registry=https://registry.npmjs.org/
@mycompany:registry=https://npm.mycompany.com/
# 5. Genera e verifica SBOM (Software Bill of Materials)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json
// package.json - usa versioni esatte, non range
{
"dependencies": {
"express": "4.21.2",
"helmet": "8.0.0",
"cors": "2.8.5"
},
"overrides": {
"vulnerable-transitive-dep": "2.1.0"
}
}
Lista kontrolna łańcucha dostaw dla projektów Angular
- Uruchomić
npm auditw każdym rurociągu CI/CD z progiem blokowania - USA Zależny robot o Odnawiać do automatycznych aktualizacji
- Aktywuj 2FA na wszystkich kontach opiekunów npm
- Sprawdź źródło pakietów przed ich zainstalowaniem (
npm info) - Wygeneruj SBOM dla każdego wydania i monitoruj je za pomocą dedykowanych narzędzi
- USA
npm ci(Nienpm install) we wszystkich zautomatyzowanych środowiskach - Skonfiguruj jeden lista dozwolonych autoryzowanych rejestrów w
.npmrc
A04-A07: Przegląd potwierdzonych kategorii
A04:2025 - Awarie kryptograficzne
Spadł z miejsca 2 na 4, ale pozostaje krytyczną luką. Dotyczy to niewystarczającej ochrony dane wrażliwe: hasła zapisane jawnym tekstem lub ze słabymi skrótami (MD5, SHA1), klucze kryptograficzne zakodowane na stałe w kodzie źródłowym, transmisja danych bez protokołu HTTPS i przestarzałe algorytmy szyfrowania.
import bcrypt from 'bcrypt';
import crypto from 'crypto';
// VULNERABILE: MD5 non e sicuro per le password
const insecureHash = crypto.createHash('md5').update(password).digest('hex');
// SICURO: bcrypt con salt rounds adeguato
const SALT_ROUNDS = 12;
const secureHash = await bcrypt.hash(password, SALT_ROUNDS);
// SICURO: verifica password senza timing attack
const isValid = await bcrypt.compare(inputPassword, storedHash);
A05:2025 – Wtrysk
Liczba zastrzyków spadła z nr 3 do nr 5, co oznacza, że środki zaradcze (ORM, zapytania sparametryzowane, środek dezynfekujący) stały się powszechne. Jednakże pozostają one niebezpieczne. Obejmuje wstrzykiwanie SQL, NoSQL Wstrzykiwanie, wstrzykiwanie poleceń, wstrzykiwanie LDAP i XSS.
// VULNERABILE: concatenazione diretta
const query = `SELECT * FROM users WHERE email = '${userInput}'`;
// Input malevolo: ' OR '1'='1' --
// SICURO: query parametrizzate (PostgreSQL)
const result = await pool.query(
'SELECT * FROM users WHERE email = $1',
[userInput]
);
// SICURO: ORM con sanitizzazione automatica (TypeORM)
const user = await userRepository.findOneBy({
email: userInput // TypeORM sanitizza automaticamente
});
A06:2025 – Niebezpieczny projekt
Dotyczy usterek w projekt aplikacji, a nie we wdrażaniu. Brak modelowania zagrożeń, nieprzestrzeganie zasady najmniejszych przywilejów oraz pominięcie kontroli, takich jak ograniczanie szybkości, to przykłady niebezpiecznego projektu. The kluczowa różnica: bezpieczny projekt może zawierać błędy w implementacji, ale jest niepewny nie można tego naprawić samym lepszym kodem.
A07:2025 — Błędy uwierzytelniania
Błędy uwierzytelniania obejmują: akceptowanie słabych haseł, sesje, które nie wygasają, tokeny JWT bez ważności lub ze słabymi sekretami i bez Multi-Factor Uwierzytelnianie. Główną obroną jest wdrożenie JWT z krótkim terminem ważności i odświeżeniem tokena bezpieczną i rygorystyczną weryfikację poświadczeń.
A08-A09: Uczciwość i monitorowanie
A08:2025 — Awarie oprogramowania lub integralności danych
Kategoria ta koncentruje się na utrzymaniu zaufania i weryfikacji uczciwości oprogramowania, kodu i artefaktów na bardziej szczegółowym poziomie niż w przypadku dostaw Łańcuch (A03). Obejmuje: potok CI/CD bez sprawdzania integralności, automatyczną aktualizację bez weryfikacja podpisu, deserializacja niezaufanych danych i brak Integralność podzasobów (SRI) dla zasobów zewnętrznych.
<!-- VULNERABILE: script esterno senza verifica -->
<script src="https://cdn.example.com/lib.js"></script>
<!-- SICURO: SRI verifica l'integrita del file -->
<script
src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
crossorigin="anonymous">
</script>
A09:2025 — Błędy w logowaniu i ostrzeganiu o zabezpieczeniach
W 2025 r. zmieniono nazwę i dodano „Alerty” zamiast „Monitorowanie” w celu podkreślenia znaczenie nie tylko rejestrowania zdarzeń, ale także ich generowania aktywne alerty gdy wystąpią anomalie. Bez zorganizowanego rejestrowania i ostrzegania naruszenie może pozostać niewykryty przez miesiące.
import winston from 'winston';
const securityLogger = winston.createLogger({
level: 'info',
format: winston.format.combine(
winston.format.timestamp(),
winston.format.json()
),
defaultMeta: { service: 'auth-service' },
transports: [
new winston.transports.File({ filename: 'security.log' }),
]
});
// Eventi CRITICI da loggare e per cui generare alert
function logFailedLogin(email: string, ip: string): void {
securityLogger.warn({
event: 'FAILED_LOGIN',
email,
ip,
timestamp: new Date().toISOString(),
alert: true // Flag per il sistema di alerting
});
}
// REGOLA: 5 login falliti dallo stesso IP = alert immediato
// REGOLA: accesso admin da IP sconosciuto = alert immediato
// REGOLA: modifica permessi fuori orario = alert immediato
Co rejestrować (a czego NIE rejestrować)
- Dziennik: udane/nieudane logowania, odmowa dostępu (403), zmiany w danych wrażliwych, działania administratora
- NIE loguj: haseł, tokenów, numerów kart kredytowych, kompletnych danych osobowych
- Generuje alerty dotyczące: nietypowych wzorców logowania, dostępów z nietypowych geolokalizacji, szczytów błędów 4xx/5xx
A10:2025 – Niewłaściwe postępowanie w wyjątkowych warunkach (NOWOŚĆ)
Druga ważna wiadomość roku 2025. Ta kategoria zawiera 24 CWE związane z niewłaściwym postępowaniem w przypadku błędów, wyjątków i warunków nietypowych. Koncepcja klucz i „otwarte w przypadku awarii”: gdy aplikacja napotkała błąd, zdecyduje się udzielić dostępu lub kontynuować operację zamiast ją blokować.
Wyjątkowe warunki mogą wynikać z: braku lub niekompletności danych wejściowych, stanów środowiskowych nieoczekiwane zdarzenia (pamięć, sieć, uprawnienia), późna obsługa błędów na wysokich poziomach zamiast tam, gdzie występują, oraz wyjątki, które w ogóle nie są obsługiwane.
Klucz CWE w tej kategorii
- CWE-209: Komunikaty o błędach zawierające poufne informacje
- CWE-234: Brak obsługi brakujących parametrów
- CWE-274: Niewłaściwe zarządzanie niewystarczającymi uprawnieniami
- CWE-476: Dereferencja wskaźnika zerowego
- CWE-636: „Failing Open” – nie zawiedź bezpiecznie
Przykład: otwarcie awaryjne podczas uwierzytelniania
// VULNERABILE: fail-open - in caso di errore l'utente passa
async function verifyToken(req: Request, res: Response, next: NextFunction) {
try {
const token = req.headers.authorization?.split(' ')[1];
const decoded = jwt.verify(token!, process.env.JWT_SECRET!);
req.user = decoded;
next();
} catch (error) {
// ERRORE CRITICO: in caso di eccezione, si prosegue comunque!
console.log('Token verification failed, continuing...');
next(); // L'utente non autenticato accede alle risorse protette
}
}
// SICURO: fail-closed - in caso di errore l'accesso e negato
async function verifyToken(req: Request, res: Response, next: NextFunction) {
try {
const token = req.headers.authorization?.split(' ')[1];
if (!token) {
return res.status(401).json({ error: 'Token mancante' });
}
const decoded = jwt.verify(token, process.env.JWT_SECRET!);
req.user = decoded;
next();
} catch (error) {
// CORRETTO: in caso di errore, si blocca l'accesso
return res.status(401).json({ error: 'Autenticazione fallita' });
}
}
Przykład: wyciek informacji w wyniku błędów
// VULNERABILE: espone dettagli interni del sistema
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
res.status(500).json({
error: err.message,
stack: err.stack, // Rivela percorsi del file system
query: (err as any).sql, // Rivela struttura del database
config: (err as any).config // Potrebbe rivelare credenziali
});
});
// SICURO: messaggi generici in produzione, dettagli solo in sviluppo
const isProduction = process.env.NODE_ENV === 'production';
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
// Logga i dettagli internamente
securityLogger.error({
message: err.message,
stack: err.stack,
url: req.originalUrl,
method: req.method,
ip: req.ip
});
// Restituisci solo un messaggio generico al client
res.status(500).json({
error: isProduction
? 'Si e verificato un errore. Riprova più tardi.'
: err.message
});
});
Przykład: Wyczerpanie zasobów w wyniku nieprawidłowego zarządzania
// VULNERABILE: il file handle non viene rilasciato in caso di errore
async function processUpload(filePath: string): Promise<void> {
const handle = await fs.open(filePath, 'r');
const data = await handle.readFile(); // Se fallisce, il handle resta aperto
await processData(data);
await handle.close();
}
// SICURO: pattern try/finally per garantire il rilascio delle risorse
async function processUpload(filePath: string): Promise<void> {
let handle: fs.FileHandle | null = null;
try {
handle = await fs.open(filePath, 'r');
const data = await handle.readFile();
await processData(data);
} catch (error) {
securityLogger.error({ event: 'UPLOAD_FAILED', filePath, error });
throw new AppError('Elaborazione file fallita', 500);
} finally {
if (handle) {
await handle.close(); // Sempre eseguito, anche in caso di errore
}
}
}
Podstawowa zasada: zamknięcie w trybie awaryjnym
Ilekroć w kontekście bezpieczeństwa wystąpi wyjątek, system musi to zrobić domyślnie odmawiaj dostępu (zamknięte w przypadku awarii), nigdy nie zezwalaj (otwarte w przypadku awarii). Dotyczy to uwierzytelniania, autoryzacji, sprawdzania poprawności danych wejściowych i wszelkich decyzji co wpływa na bezpieczeństwo.
Fokus: Bezpieczeństwo kodu generowanego przez sztuczną inteligencję
Wraz z masowym przyjęciem narzędzi kodowania AI (Copilot, ChatGPT, Claude, Cursor), pojawia się nowe ryzyko: bezpieczeństwo automatycznie generowanego kodu. Według Raport dotyczący bezpieczeństwa kodu GenAI firmy Veracode za rok 2025, który przeanalizował kod opracowanych przez ponad 100 nauczycieli akademickich w ramach 80 rzeczywistych zadań, wyniki są niepokojące.
Liczby bezpieczeństwa AI
- 45% Próbki kodu wygenerowane przez sztuczną inteligencję nie przechodzą testów bezpieczeństwa i wprowadzają 10 najpopularniejszych luk w zabezpieczeniach OWASP
- 72% wskaźnik awaryjności kodu Java generowanego przez sztuczną inteligencję
- 38-45% wskaźników awaryjności w Pythonie, C# i JavaScript
- 86% określony współczynnik awaryjności dla Cross-Site Scripting (CWE-80)
- 88% określony wskaźnik awaryjności dla Log Injection (CWE-117)
Problem nie ustępuje
Modele sztucznej inteligencji w mniej więcej połowie przypadków podejmują złe decyzje dotyczące bezpieczeństwa, np nie poprawia się to w przypadku większych modeli. Problem polega na tym systemowe: modele są szkolone na kodzie publicznym, który często zawiera te same luki których powinni unikać. Kod wygenerowany przez sztuczną inteligencję zawsze wymaga przeglądu bezpieczeństwa człowiek.
Lista kontrolna zabezpieczeń dla kodu generowanego przez sztuczną inteligencję
- Nigdy nie akceptuj bez niego kodu wygenerowanego przez sztuczną inteligencję przegląd kodu bezpieczeństwa
- Sprawdź, czy zapytania do bazy danych są sparametryzowane (bez łączenia)
- Sprawdź, czy dane wprowadzone przez użytkownika to sprawdzone i zdezynfekowane w każdym punkcie
- Upewnij się, że tajemnice nie są zakodowane na stałe w wygenerowanym kodzie
- Sprawdź obsługę błędów - musi tak być zamknięte, nie jest otwarty
- Sprawdź uprawnienia i autoryzację: sztuczna inteligencja często generuje kod bez kontroli dostępu
- Uruchomić SAST (Statyczne testowanie bezpieczeństwa aplikacji) zautomatyzowane dla całego kodu generowanego przez sztuczną inteligencję
Lista kontrolna zabezpieczeń specyficzna dla Angular
Angular oferuje wiele wbudowanych zabezpieczeń, jednak warto je znać nie wyłączaj ich przypadkowo. Oto lista kontrolna dotycząca aplikacji Angular:
Zintegrowana ochrona XSS
import { DomSanitizer, SafeHtml } from '@angular/platform-browser';
// Angular sanitizza automaticamente il binding nel template
// Le doppie graffe eseguono l'escape dell'HTML automaticamente
// PERICOLOSO: bypassare il sanitizer
@Component({
template: `<div [innerHTML]="trustedHtml"></div>`
})
export class UnsafeComponent {
trustedHtml: SafeHtml;
constructor(private sanitizer: DomSanitizer) {
// SOLO se il contenuto e completamente fidato e sotto il tuo controllo
this.trustedHtml = this.sanitizer.bypassSecurityTrustHtml(content);
}
}
// SICURO: lasciare che Angular sanitizzi automaticamente
@Component({
template: `<div [textContent]="userContent"></div>`
})
export class SafeComponent {
userContent = ''; // Angular esegue l'escape automaticamente
}
HttpClient i Security Interceptor
import { HttpInterceptorFn, HttpErrorResponse } from '@angular/common/http';
import { inject } from '@angular/core';
import { Router } from '@angular/router';
import { catchError, throwError } from 'rxjs';
export const authInterceptor: HttpInterceptorFn = (req, next) => {
const router = inject(Router);
const token = getStoredToken(); // Da un servizio sicuro
// Aggiungi il token solo alle richieste verso la tua API
const secureReq = req.url.startsWith('/api')
? req.clone({
setHeaders: { Authorization: `Bearer ${token}` }
})
: req;
return next(secureReq).pipe(
catchError((error: HttpErrorResponse) => {
if (error.status === 401) {
// Token scaduto o invalido: redirect al login
router.navigate(['/login']);
}
// Non esporre dettagli dell'errore nell'interfaccia
return throwError(() => new Error('Richiesta fallita'));
})
);
};
Strażnik trasy z funkcjonalnym API
import { CanActivateFn, Router } from '@angular/router';
import { inject } from '@angular/core';
export const authGuard: CanActivateFn = (route, state) => {
const authService = inject(AuthService);
const router = inject(Router);
if (!authService.isAuthenticated()) {
// Redirect al login con URL di ritorno
router.navigate(['/login'], {
queryParams: { returnUrl: state.url }
});
return false;
}
// Verifica ruolo se richiesto dalla rotta
const requiredRole = route.data?.['role'];
if (requiredRole && !authService.hasRole(requiredRole)) {
router.navigate(['/unauthorized']);
return false;
}
return true;
};
Polityka bezpieczeństwa treści dla Angular
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-RANDOM_VALUE';
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
img-src 'self' data: https:;
connect-src 'self' https://api.tuodominio.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
Ostateczna lista kontrolna Angulara
- Nie używać
bypassSecurityTrustHtmlz treścią użytkownika - USA
HttpClientz przechwytywaczem tokenów i scentralizowanym zarządzaniem błędami - Narzędzie Funkcjonalni strażnicy tras dla wszystkich chronionych tras
- Skonfiguruj jeden Restrykcyjne CSP na serwerze obsługującym aplikację Angular
- Nie przechowuj tokenów JWT w
localStorage: wolę ciasteczkaHttpOnly - Ważny zawsze po stronie serwera: Osłony kątowe chronią tylko interfejs użytkownika, a nie interfejs API
- Użyj flagi
--subresource-integrityinng builddo generowania skrótów SRI - Aktualizuj Angular: każda wersja zawiera poprawki bezpieczeństwa
Wnioski i plan działania
Lista 10 najlepszych zagrożeń OWASP 2025 odzwierciedla szybko zmieniający się krajobraz zagrożeń. Dwóch nowych kategorie, Awarie łańcucha dostaw i Niewłaściwe postępowanie w wyjątkowych warunkach, nie są dodawane akademickie: reprezentują konkretne zagrożenia, które na co dzień wpływają na rzeczywiste zastosowania. The Awans Security Misconfiguration na drugie miejsce potwierdza, że złożoność Nowoczesna infrastruktura stwarza coraz większe powierzchnie ataku.
Plan działania dewelopera
Oto praktyczna, składająca się z trzech kroków ścieżka poprawy bezpiecznej postawy aplikacje:
- Tydzień 1 – Podstawy: Zaimplementuj kontrolę dostępu do wszystkich interfejsów API (A01), skonfiguruj nagłówki zabezpieczeń za pomocą Helmet (A02) i włącz
npm auditw rurociągu CI/CD (A03) - Tydzień 2 – Ochrona danych: Przeprowadź migrację do bcrypt/argon2 dla haseł (A04), upewnij się, że wszystkie zapytania są sparametryzowane (A05) i zaimplementuj ograniczenie szybkości (A06)
- Tydzień 3 – Monitorowanie: Skonfiguruj rejestrowanie strukturalne z alertami (A09), przejrzyj wszystkie bloki catch, aby wyeliminować awarię (A10) i wygeneruj SBOM zależności (A03)
Następne artykuły z serii
W przyszłych artykułach będziemy zagłębiać się w poszczególne obszary bezpieczeństwa w sieci, korzystając z praktycznych poradników i pełny kod:
- Artykuł 02: XSS i CSRF - Ataki między witrynami i jak im zapobiegać w Angular
- Artykuł 03: Wstrzykiwanie SQL i Wstrzykiwanie NoSQL — szczegółowe zapoznanie się z Node.js i MongoDB
- Artykuł 04: Bezpieczne uwierzytelnianie — JWT, OAuth2 i sesje
Bezpieczeństwo aplikacji internetowych nie jest punktem kontrolnym, który można przejść tylko raz: jest to: proces ciągły które należy uwzględnić na każdym etapie rozwoju, od projektu po produkcję. Jako programiści jesteśmy odpowiedzialni za pisanie kodu domyślnie bezpieczny. 10 najważniejszych luk w zabezpieczeniach OWASP stanowi absolutne minimum wiedzieć. Koszt zapobiegania podatności jest zawsze niższy niż koszt ponieść konsekwencje.







