Workflow audytu bezpieczeństwa w Cursor

Twój zespół jest trzy tygodnie od uruchomienia produktu SaaS, który obsługuje dane płatnicze klientów, przechowuje dane osobowe i eksponuje publiczne API. Przegląd bezpieczeństwa miał się odbyć w poprzednim sprincie, ale ciągle był przesuwany. Teraz oficer ds. compliance pyta o ocenę bezpieczeństwa, a twój budżet na testy penetracyjne wynosi dokładnie zero złotych. Potrzebujesz dokładnego audytu i potrzebujesz go szybko.

Audyt bezpieczeństwa wspomagany AI nie zastępuje profesjonalnego pentestu. Ale wyłapuje zaskakującą liczbę typowych podatności — SQL injection, XSS, niebezpieczna autentykacja, ujawnione sekrety, brak rate limitingu — które odpowiadają za zdecydowaną większość rzeczywistych naruszeń. Poniższy workflow systematycznie przegląda twoją bazę kodu pod kątem kategorii OWASP Top 10 i produkuje priorytetyzowaną listę ustaleń z konkretnymi poprawkami.

Co wyniesiesz z tej lekcji

• Kompleksowy prompt audytu bezpieczeństwa, który skanuje bazę kodu pod kątem podatności OWASP Top 10
• Prompt przeglądu autentykacji, który sprawdza obsługę sesji, przechowywanie haseł i zarządzanie tokenami
• Workflow audytu zależności, który znajduje znane CVE w twoich pakietach npm/pip/cargo
• Prompt detekcji sekretów, który wyłapuje przypadkowo zacommitowane klucze API, tokeny i poświadczenia
• Prompt napraw bezpieczeństwa, który łata podatności bez psucia istniejącej funkcjonalności

Workflow

Krok 1: Uruchom automatyczny audyt zależności

Zacznij od najłatwiejszych wygranych — znanych podatności w twoich zależnościach. To zajmuje sekundy i często znajduje krytyczne problemy.

Wskazówka

Prompt do skopiowania — Audyt bezpieczeństwa zależności:

Uruchom te komendy i przeanalizuj wyniki:

1. npm audit --json (lub pip audit --format json / cargo audit --json)
2. Zaraportuj każdą podatność o severity HIGH lub CRITICAL
3. Dla każdej podatności powiedz mi:
   • Który pakiet jest dotknięty i której wersji używamy
   • Co podatność pozwala atakującemu zrobić
   • Czy istnieje zpatchowana wersja
   • Czy aktualizacja zepsuje nasz kod (sprawdź nasze użycie importów)
4. Wygeneruj komendy do naprawy każdej z nich, zaczynając od aktualizacji o najniższym ryzyku
5. Dla każdej podatności, gdzie nie istnieje patch, zasugeruj mitygację lub alternatywny pakiet

NIE naprawiaj automatycznie bez pokazania mi planu.

Agent uruchomi komendę audytu, sparsuje output JSON i da ci priorytetyzowany plan naprawczy. Aktualizuj pakiety niskiego ryzyka natychmiast. Dla zmian łamiących kompatybilność twórz osobne gałęzie.

Krok 2: Skanuj w poszukiwaniu zahardkodowanych sekretów

Przypadkowo zacommitowane sekrety to błąd bezpieczeństwa numer jeden w bazach kodu. Gdy sekret jest w historii git, jest skompromitowany permanentnie, nawet jeśli usuniesz plik.

Wskazówka

Prompt do skopiowania — Detekcja sekretów:

@src @config @scripts

Przeskanuj całą bazę kodu w poszukiwaniu przypadkowo zacommitowanych sekretów:

1. Klucze API (wzorce: sk_live_, pk_live_, AKIA, ghp_, gho_, xoxb-, xoxp-)
2. Connection stringi bazy danych z hasłami
3. Sekrety JWT lub klucze podpisujące
4. Sekrety klienta OAuth
5. Klucze prywatne (RSA, ECDSA, Ed25519)
6. Zmienne środowiskowe używane bezpośrednio zamiast z process.env
7. Pliki .env śledzone przez git (sprawdź .gitignore)
8. Zahardkodowane hasła lub tokeny w plikach testowych pasujące do wzorców produkcyjnych
9. URL-e z poświadczeniami w parametrach query lub basic auth

Dla każdego znaleziska:

• Dokładny plik i numer linii
• Jaki to typ sekretu
• Severity: CRITICAL (poświadczenie produkcyjne), HIGH (może być produkcyjne), MEDIUM (test/development)
• Naprawa: jak prawidłowo przechowywać ten sekret

Sprawdź również: Czy .env jest w .gitignore? A .env.local? Czy są jakieś pliki .env w historii git (nawet jeśli usunięte)?

Krok 3: Audytuj autentykację i autoryzację

Błędy autentykacji są często najpoważniejsze, ponieważ pozwalają atakującym podszywać się pod legalnych użytkowników. Użyj trybu Ask do dokładnego przeglądu.

@src/auth @src/middleware @src/api

Przejrzyj implementację autentykacji i autoryzacji:

1. Obsługa haseł:
   - Czy hasła są hashowane za pomocą bcrypt/scrypt/argon2 (nie MD5/SHA1)?
   - Czy jest minimalna długość hasła i wymaganie złożoności?
   - Czy jest ochrona przed brute force (rate limiting na logowaniu)?

2. Zarządzanie sesjami:
   - Jak przechowywane są sesje (cookie, JWT, baza danych)?
   - Czy sesje wygasają? Jaki jest timeout?
   - Czy istnieje mechanizm wylogowania, który faktycznie unieważnia sesję?
   - Czy tokeny sesji są regenerowane po zalogowaniu (zapobieganie session fixation)?

3. Autoryzacja:
   - Czy każdy endpoint API jest sprawdzany pod kątem autoryzacji?
   - Czy są endpointy, które powinny wymagać auth, ale nie wymagają?
   - Czy jest ochrona przed IDOR (czy użytkownik A może uzyskać dostęp do danych użytkownika B zmieniając ID)?
   - Czy endpointy administracyjne są wydzielone i zabezpieczone?

4. Obsługa tokenów:
   - Czy JWT są weryfikowane z prawidłowym algorytmem (nie "none")?
   - Czy sekret JWT jest wystarczająco silny (co najmniej 256 bitów)?
   - Czy refresh tokeny są przechowywane bezpiecznie?
   - Czy tokeny mogą być odwołane?

Dla każdego znalezionego problemu oceń severity (CRITICAL, HIGH, MEDIUM, LOW) i podaj poprawkę.

Krok 4: Sprawdź podatności na injection

SQL injection, XSS i command injection nadal należą do najczęściej eksploatowanych podatności w aplikacjach webowych.

Wskazówka

Prompt do skopiowania — Skanowanie podatności na injection:

@src/api @src/components @src/db

Przeskanuj w poszukiwaniu podatności na injection:

1. SQL Injection:

   • Znajdź jakiekolwiek surowe zapytania SQL, które konkatenują input użytkownika (interpolacja stringów w SQL)
   • Zweryfikuj, że wszystkie zapytania ORM używają sparametryzowanych inputów
   • Sprawdź dynamiczne nazwy tabel/kolumn pochodzące z inputu użytkownika
   • Szukaj wywołań .raw() lub .unsafeRaw()

2. Cross-Site Scripting (XSS):

   • Znajdź jakiekolwiek użycie dangerouslySetInnerHTML w komponentach React
   • Sprawdź, czy treści generowane przez użytkowników są sanityzowane przed renderowaniem
   • Szukaj parametrów URL odzwierciedlanych w outputcie strony bez kodowania
   • Zweryfikuj, czy nagłówki Content-Security-Policy są ustawione

3. Command Injection:

   • Znajdź jakiekolwiek wywołania exec(), spawn() lub system() z inputem użytkownika
   • Sprawdź template literals w komendach shell
   • Szukaj wywołań eval() lub Function() z dynamicznym inputem

4. Path Traversal:

   • Znajdź operacje odczytu/zapisu plików używające ścieżek dostarczonych przez użytkownika
   • Sprawdź wzorce ../../../ w obsłudze plików
   • Zweryfikuj, czy ścieżki uploadowanych plików są sanityzowane

Dla każdego znaleziska pokaż podatny kod i bezpieczną alternatywę.

Krok 5: Przejrzyj bezpieczeństwo API

Publiczne API potrzebują wielowarstwowej obrony — rate limiting, walidacja inputu, prawidłowa obsługa błędów i konfiguracja CORS.

@src/api @src/middleware

Audytuj bezpieczeństwo API:

1. Rate limiting:
   - Czy jest rate limiting na endpointach autentykacji?
   - Czy jest rate limiting na publicznych endpointach API?
   - Jakie są limity i czy są odpowiednie?
   - Czy rate limity można obejść zmieniając nagłówki (X-Forwarded-For)?

2. Walidacja inputu:
   - Czy każdy endpoint API waliduje input za pomocą schematu (Zod, Joi, itp.)?
   - Czy uploady plików są walidowane pod kątem typu, rozmiaru i zawartości?
   - Czy parametry query są sanityzowane?
   - Czy rozmiar ciała żądania jest ograniczony?

3. Obsługa błędów:
   - Czy odpowiedzi błędów ujawniają stack trace lub wewnętrzne ścieżki?
   - Czy błędy bazy danych są przechwytywane i zastępowane generycznymi komunikatami?
   - Czy istnieje globalny handler błędów zapobiegający wyciekom nieobsłużonych wyjątków?

4. Konfiguracja CORS:
   - Czy Access-Control-Allow-Origin jest konkretny (nie wildcard *)?
   - Czy dozwolone są tylko niezbędne metody HTTP?
   - Czy poświadczenia są prawidłowo ograniczone?

5. Nagłówki:
   - Czy Strict-Transport-Security jest ustawiony?
   - Czy X-Content-Type-Options: nosniff jest ustawiony?
   - Czy X-Frame-Options jest ustawiony, aby zapobiec clickjackingowi?
   - Czy ciasteczka mają flagi Secure, HttpOnly i SameSite?

Krok 6: Zaimplementuj poprawki w trybie Agent

Gdy masz priorytetyzowaną listę ustaleń, użyj trybu Agent do implementacji poprawek. Zacznij od problemów o severity CRITICAL i HIGH.

Wskazówka

Prompt do skopiowania — Implementacja poprawek bezpieczeństwa:

Na podstawie ustaleń audytu bezpieczeństwa zaimplementuj te poprawki w kolejności priorytetów:

CRITICAL:

1. Usuń zahardkodowane hasło do bazy z src/config/database.ts — przenieś do zmiennej środowiskowej
2. Dodaj sparametryzowane zapytania do 3 punktów SQL injection w src/api/search.ts
3. Dodaj rate limiting do endpointu logowania (max 5 prób na minutę per IP)

HIGH: 4. Dodaj nagłówek Content-Security-Policy do middleware 5. Sanityzuj treści HTML generowane przez użytkowników przed renderowaniem (użyj DOMPurify) 6. Ustaw wszystkie flagi ciasteczek: Secure, HttpOnly, SameSite=Strict 7. Dodaj ochronę CSRF do wszystkich endpointów zmieniających stan

Dla każdej poprawki:

• Wprowadź zmianę
• Dodaj test weryfikujący, że podatność jest załatana
• Uruchom istniejące testy, aby zweryfikować, że nic się nie zepsuło

NIE commituj zmian — chcę najpierw przejrzeć diff.

Krok 7: Skonfiguruj ciągły monitoring bezpieczeństwa

Jednorazowy audyt pomaga, ale bezpieczeństwo wymaga ciągłej uwagi. Skonfiguruj automatyczne sprawdzenia w swoim pipeline’ie CI.

Skonfiguruj automatyczne sprawdzenia bezpieczeństwa:

1. Dodaj npm audit do pipeline'u CI -- zawal build przy podatnościach HIGH/CRITICAL
2. Dodaj hook git pre-commit, który skanuje w poszukiwaniu sekretów za pomocą detect-secrets lub gitleaks
3. Dodaj SAST (Static Application Security Testing) za pomocą pluginów ESLint bezpieczeństwa:
   - eslint-plugin-security dla wzorców Node.js
   - eslint-plugin-no-unsanitized dla DOM XSS
4. Dodaj plik .cursor/rules/security.mdc instruujący Cursor, aby:
   - Zawsze używał sparametryzowanych zapytań
   - Nigdy nie używał dangerouslySetInnerHTML bez sanityzacji
   - Zawsze walidował input za pomocą Zod przed przetworzeniem
   - Nigdy nie logował wrażliwych danych (hasła, tokeny, PII)

Utwórz krok workflow CI i plik reguł.

Kiedy to się psuje

AI nie wyłapuje podatności logiki biznesowej. Automatyczne skanowanie wyłapuje podatności oparte na wzorcach (SQL injection, XSS), ale ma trudności z błędami logiki biznesowej typu “użytkownik może zmienić cenę produktu modyfikując ciało żądania” lub “usunięcie konta nie unieważnia aktywnych kluczy API.” Dla podatności logiki potrzebujesz ręcznego modelowania zagrożeń. Użyj trybu Ask do burzy mózgów scenariuszy ataku: “Gdybyś był atakującym próbującym ukraść pieniądze z tego systemu checkoutowego, czego byś próbował?”

False positive’y marnują czas. AI oznaczy niektóre wzorce jako podatne, które w kontekście są bezpieczne (np. sparametryzowane zapytanie, które wygląda jak konkatenacja stringów z powodu sposobu, w jaki ORM je generuje). Zweryfikuj każde ustalenie przed naprawą. False positive, który “naprawisz”, może wprowadzić prawdziwego buga.

Poprawki psują funkcjonalność. Zmiany bezpieczeństwa są znane z psucia legalnych funkcji. Dodanie ochrony CSRF może zepsuć klientów API, którzy nie wysyłają tokenów. Ustawienie ścisłego CORS może zablokować legalne żądania frontendu. Zawsze uruchamiaj pełny zestaw testów po poprawkach bezpieczeństwa i testuj ręcznie z perspektywy użytkownika.

Aktualizacje zależności wprowadzają zmiany łamiące kompatybilność. Aktualizacja pakietu w celu naprawy CVE może zepsuć aplikację, jeśli nowa wersja ma zmiany API. Przypinaj dokładne wersje w package.json, aktualizuj jedną zależność naraz i uruchamiaj testy po każdej aktualizacji. Dla major version bumpów czytaj changelog przed aktualizacją.

Audyt tworzy fałszywe poczucie bezpieczeństwa. Skan AI, który mówi “nie znaleziono podatności”, nie oznacza, że twoja aplikacja jest bezpieczna. Oznacza, że nie wykryto znanych wzorców. Profesjonalne testy penetracyjne, modelowanie zagrożeń i przegląd architektury bezpieczeństwa nadal są konieczne dla aplikacji obsługujących wrażliwe dane.

Co dalej

Generowanie dokumentacji Udokumentuj swoje praktyki bezpieczeństwa, autentykację API i procedury reagowania na incydenty.

Integracja API Przejrzyj integracje z zewnętrznymi API pod kątem bezpieczeństwa: weryfikacja webhooków, rotacja kluczy, obsługa danych.

Prywatność i bezpieczeństwo Głębokie zanurzenie w modelu bezpieczeństwa samego Cursor, tryb prywatności i obsługę danych.