Bezpieczeństwo kodu, który piszesz z Cursorem

„Bezpieczeństwo Cursora" oznacza dwie różne rzeczy i warto je rozdzielić. Pierwsza to zabezpieczenie własnej konfiguracji Cursora: co opuszcza Twoją maszynę, co agent może wykonać bez pytania i którym serwerom oraz plikom reguł ufasz. Druga to zabezpieczenie kodu, który Cursor pisze za Ciebie, bo to on trafia na produkcję i jest wystawiony do internetu. Ten poradnik obejmuje obie, z blokiem reguł gotowym do wklejenia do projektu i promptem przeglądu przed każdym wdrożeniem.

Część 1: zabezpieczenie konfiguracji Cursora

Co opuszcza Twoją maszynę

Cursor wysyła na swoje serwery, i na serwery dostawcy modelu, kontekst potrzebny do odpowiedzi: otwarty plik, to, co indeksuje z projektu, i wszystko, co wklejasz do czatu. Włącz tryb prywatności w ustawieniach, jeśli nie chcesz, żeby ten kod był przechowywany ani używany do treningu; w zespołach wymuś go z poziomu planu. I pamiętaj, że wszystko, co wkleisz do czatu, podróżuje: nie wklejaj zrzutów bazy danych ani plików z poświadczeniami „żeby zrozumiał".

Wyklucz sekrety z indeksowania

Cursor indeksuje projekt, żeby dać modelowi kontekst. Plik .env, service-account.json czy folder z certyfikatami nie powinny być częścią tego indeksu. Utwórz w katalogu głównym plik .cursorignore z wzorcami do wykluczenia; używa składni .gitignore:

.env
.env.*
*.pem
*.key
**/service-account*.json
secrets/

Jeśli coś wrażliwego było już zaindeksowane, usuń to z indeksu w ustawieniach, a jeśli to był prawdziwy klucz, zrotuj go.

Automatyczne wykonywanie poleceń

Agent Cursora może samodzielnie wykonywać polecenia w terminalu, jeśli mu na to pozwolisz. To wygodne i niebezpieczne: źle zrozumiany prompt albo złośliwy tekst, który agent przeczyta z pliku lub strony, może skończyć się na rm -rf, git push --force albo curl | sh. Zostaw ręczne potwierdzanie dla poleceń, które usuwają, publikują lub instalują, używaj listy dozwolonych tylko do nieszkodliwych rzeczy (testy, lint, build) i nigdy nie dawaj agentowi poświadczeń produkcyjnych w środowisku.

Serwery MCP firm trzecich

Serwery MCP rozszerzają możliwości agenta: czytanie Twojej bazy danych, wywoływanie API, sterowanie przeglądarką. Każdy z nich to kod działający z Twoimi uprawnieniami, a opisy jego narzędzi model czyta jak instrukcje. Instaluj tylko serwery ze znanych źródeł, sprawdzaj, o co proszą, preferuj te działające na poświadczeniach tylko do odczytu i pilnuj zmian konfiguracji: serwer, który zmienia swoją definicję po tym, jak go zatwierdziłeś, to sygnał alarmowy.

Pliki reguł z cudzych repozytoriów

Pliki reguł (.cursor/rules, .cursorrules) to instrukcje, których model słucha przy każdym żądaniu. Jeśli klonujesz repozytorium, szablon albo przykład z internetu, może on zawierać reguły, których nie widać na pierwszy rzut oka, nawet z niewidocznymi znakami ukrywającymi instrukcje do przemycenia złośliwego kodu. Otwórz i przeczytaj pliki reguł każdego projektu, którego nie napisałeś sam, zanim pozwolisz agentowi w nim pracować.

Aktualizuj Cursora

Jak każdy edytor z agentem w środku, Cursor miał własne luki bezpieczeństwa, kilka związanych z zaufaniem do przestrzeni roboczych i z MCP. Aktualizuj, gdy wychodzi nowa wersja, i nie otwieraj projektów wątpliwego pochodzenia z włączonym automatycznym wykonywaniem.

Część 2: luki, które Cursor wkłada do Twojego kodu

Model optymalizuje pod to, żeby kod działał, nie żeby był bezpieczny. Oto wzorce, które najczęściej powtarzają się w aplikacjach pisanych z Cursorem, i jak je wykryć:

• Sekrety zaszyte na sztywno. Żeby przykład szybko ruszył, klucz ląduje w kodzie albo w publicznej zmiennej. Poszukaj w bundle'u sk_live, service_role, AKIA i -----BEGIN. Więcej w sekretach, które Twoja aplikacja wycieka w przeglądarce.
• Otwarty CORS i wyłączona autoryzacja „żeby zadziałało". W obliczu błędu typowa podpowiedź to odbijanie dowolnego źródła albo pominięcie sprawdzania sesji. W danej chwili działa i zostawia otwarte drzwi na produkcji.
• Endpointy ufające klientowi. Route'y, które przyjmują user_id, rolę albo cenę z ciała żądania bez sprawdzenia na serwerze.
• Brak nagłówków bezpieczeństwa. Wygenerowany kod prawie nigdy nie dodaje CSP, HSTS ani X-Frame-Options; sprawdź to narzędziem do nagłówków.
• Stare zależności. Model proponuje wersje, które zna, a nie najnowsze. Uruchom npm audit przed wdrożeniem.

Blok reguł bezpieczeństwa dla Twojego projektu

Najbardziej opłacalne, co możesz zrobić, to raz na zawsze powiedzieć modelowi, czego nie wolno mu robić. Wklej to do .cursor/rules/security.mdc (albo do .cursorrules) z regułą ustawioną na „stosuj zawsze". Jest po angielsku, bo w tym języku model słucha najlepiej:

# Security rules (always apply)
- Never hardcode API keys, tokens or passwords. Read them from
  environment variables on the server only.
- Never put secrets in variables prefixed NEXT_PUBLIC_, VITE_ or NUXT_PUBLIC_.
- Never disable authentication, authorization or Row Level Security
  to make something work. Fix the policy instead and explain why.
- CORS: allow only an explicit list of origins. Never reflect the
  request origin together with credentials.
- Validate input and authorize every API route on the server, even if
  the UI hides the action.
- Set security headers: CSP, HSTS, X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy.
- Session cookies must be Secure, HttpOnly and SameSite=Lax.
- Add a dependency only when necessary, pinned to a maintained version.
- If a request conflicts with these rules, stop and explain the
  security trade-off before writing code.

Prompt przeglądu przed wdrożeniem

Przed każdym wdrożeniem otwórz nowy czat z całym projektem w kontekście i poproś: „Przejrzyj ten projekt jako audytor bezpieczeństwa przed wdrożeniem. Wypisz każdy sekret, który trafia do kodu klienta, każdy route API bez sprawdzania sesji lub uprawnień, każdą poluzowaną regułę CORS lub RLS, brakujące nagłówki bezpieczeństwa i ciasteczka bez Secure, HttpOnly lub SameSite. Przy każdym znalezisku podaj plik, linię i poprawkę. Nie zmieniaj jeszcze kodu." Potem napraw znaleziska po kolei i poproś o przegląd ponownie.

Sprawdź wynik z zewnątrz

Model przegląda kod, który widzi; liczy się to, co widzi atakujący. Po wdrożeniu uruchom Scanaris na publicznym adresie: wykrywa sekrety w JavaScripcie, liberalny CORS, źle ustawione nagłówki i ciasteczka, dostępne wrażliwe pliki i wersje ze znanymi podatnościami, i do każdego znaleziska daje prompt do wklejenia w Cursorze. Jeśli zostawisz monitoring, ostrzeże Cię, gdy sesja vibe codingu znów otworzy coś, co było już zamknięte. Pełną mapę znajdziesz w poradniku bezpieczeństwa aplikacji tworzonych przez AI i w checkliście startowej.

Najczęściej zadawane pytania

Czy używanie Cursora z kodem firmowym jest bezpieczne?

Z włączonym trybem prywatności, sekretami wykluczonymi z indeksu i bez wklejania prawdziwych danych do czatu ryzyko jest porównywalne z dowolnym narzędziem w chmurze. Sprawdź polityki swojej firmy i w razie potrzeby użyj planu zespołowego, żeby wymusić konfigurację.

Czy kod pisany przez Cursora jest mniej bezpieczny niż pisany ręcznie?

Niekoniecznie, ale zawodzi w przewidywalnych miejscach: sekrety, przeszkadzające uprawnienia i konfiguracja, o którą nikt nie prosił. Z jasnymi regułami i przeglądem przed wdrożeniem wynik jest zwykle lepszy od średniej.

Co zrobić, jeśli agent już wykonał coś, czego nie powinien?

Zrotuj wszystkie poświadczenia, do których miał dostęp, przejrzyj historię gita i terminala, żeby zobaczyć, czego dotknął, i ogranicz automatyczne wykonywanie, zanim pójdziesz dalej.