Security Checklist

assadante.com

Security Checklist

Kompleksowe zabezpieczenia aplikacji webowych i mobilnych. Bazowane na OWASP Top 10 (2021), NIST i best practices branżowych. Użyj przed launch i jako regularny audyt co kwartał.

1. Autentykacja (OWASP A07: Identification & Authentication Failures)

• Hasła hashowane algorytmem bcrypt, Argon2 lub scrypt
  Nigdy MD5, SHA1, SHA256 bez soli — są zbyt szybkie do brute-force. bcrypt: min. cost factor 12. Argon2id: rekomendowany przez OWASP od 2023.
• Sól (salt) unikalna dla każdego hasła
  Zapobiega atakom rainbow table. bcrypt i Argon2 generują sól automatycznie.
• Wymuszanie silnych haseł (min. 12 znaków)
  NIST 2024: min. 8 znaków, ale 12+ rekomendowane. Sprawdzaj hasła w bazie Have I Been Pwned (API). Nie wymuszaj zbyt skomplikowanych reguł — to skłania do słabych haseł.
• Rate limiting na endpoint logowania
  Max 5 prób / 15 min per IP + per konto. Po przekroczeniu: CAPTCHA lub tymczasowy lockout (nie permanentny — to DoS vector).
• Bezpieczne sesje i tokeny JWT
  HttpOnly + Secure + SameSite=Strict cookies. JWT: krótki czas życia (15–60 min), refresh token w HttpOnly cookie. Nigdy JWT w localStorage — podatne na XSS.
• 2FA / MFA dostępne i wymuszone dla adminów
  TOTP (Google Authenticator, Authy) > SMS (podatne na SIM swapping). Dla kont uprzywilejowanych: wymuś MFA. Dla zwykłych: zachęcaj.
• Bezpieczny reset hasła
  Token jednorazowy, ważny max 15 minut, wysyłany na email. Nie pytaj o "pytania bezpieczeństwa" — są słabe. Nie ujawniaj czy email istnieje w systemie.
• Wylogowanie unieważnia sesję po stronie serwera
  Nie tylko usuwa cookie — token musi być unieważniony w bazie/cache. Dotyczy też JWT (blacklista lub krótki TTL).
• Ochrona przed credential stuffing
  Atakujący testują listy wykradzionych loginów/haseł. Obrona: rate limiting, CAPTCHA, monitoring anomalii, Have I Been Pwned API przy rejestracji.

2. Autoryzacja (OWASP A01: Broken Access Control)

• Sprawdzanie uprawnień na backendzie przy każdym żądaniu
  Nigdy nie ufaj frontendowi. Ukrycie przycisku w UI ≠ zabezpieczenie. Każdy endpoint API musi weryfikować uprawnienia niezależnie.
• Ochrona przed IDOR (Insecure Direct Object Reference)
  User A nie może zobaczyć danych User B przez zmianę ID w URL (/api/users/123 → /api/users/124). Używaj UUID zamiast sekwencyjnych ID lub weryfikuj własność zasobu.
• Principle of Least Privilege (PoLP)
  Użytkownicy i serwisy mają tylko te uprawnienia, których potrzebują. Konto bazy danych aplikacji nie powinno mieć uprawnień DROP TABLE.
• RBAC (Role-Based Access Control) lub ABAC zaimplementowane
  Jasno zdefiniowane role (admin, user, moderator) z listą dozwolonych akcji. Zmiany uprawnień logowane.
• Brak funkcji administracyjnych dostępnych dla zwykłych użytkowników
  Panel admina pod osobną domeną lub z dodatkową autentykacją. Endpointy /admin/* chronione middleware.
• Dostęp do plików i zasobów statycznych kontrolowany
  Pliki użytkowników nie są publicznie dostępne bez autoryzacji. Używaj signed URLs (S3, GCS) z krótkim TTL.

3. Walidacja danych wejściowych (OWASP A03: Injection)

• Walidacja wszystkich inputów — whitelist, nie blacklist
  Definiuj co jest dozwolone (typ, długość, format, zakres), nie co jest zakazane. Waliduj po stronie serwera — walidacja frontendowa to tylko UX.
• Ochrona przed SQL Injection
  Parameterized queries lub ORM (Prisma, SQLAlchemy, Hibernate). Nigdy string concatenation w zapytaniach SQL. Test: wpisz ' OR '1'='1 w pole logowania.
• Ochrona przed NoSQL Injection
  MongoDB, Firebase: waliduj typy danych. Atakujący może wstrzyknąć obiekt {$gt: ""} zamiast stringa.
• Ochrona przed XSS (Cross-Site Scripting)
  Escape output w HTML (htmlspecialchars, DOMPurify). Content Security Policy (CSP) header. Nigdy innerHTML z danymi użytkownika.
• Ochrona przed Command Injection
  Jeśli wywołujesz komendy systemowe — nigdy nie wstrzykuj danych użytkownika. Używaj bibliotek zamiast exec/shell_exec.
• Walidacja plików uploadowanych
  Sprawdzaj MIME type (nie tylko extension), rozmiar, skanuj antywirusem (ClamAV). Przechowuj poza webroot. Serwuj przez CDN, nie bezpośrednio.
• Ochrona przed SSRF (Server-Side Request Forgery)
  Jeśli aplikacja pobiera URL podany przez użytkownika — waliduj i whitelist dozwolone domeny. Blokuj dostęp do 169.254.x.x (AWS metadata).

4. Transport & Szyfrowanie danych

• HTTPS wszędzie — TLS 1.2 minimum, TLS 1.3 rekomendowane
  HSTS header (Strict-Transport-Security: max-age=31536000; includeSubDomains). Redirect HTTP → HTTPS. Sprawdź: ssllabs.com/ssltest.
• Wrażliwe dane szyfrowane w spoczynku (at rest)
  PII (imię, email, PESEL), dane płatnicze, tokeny API — szyfrowane w bazie (AES-256). Dane płatnicze: używaj Stripe/Braintree — nie przechowuj kart samodzielnie.
• Sekrety i klucze API w secret managerze
  AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Firebase Functions config. Nigdy w kodzie, nigdy w .env commitowanym do repo.
• Backupy szyfrowane i testowane
  Backup bez testu restore = brak backupu. Testuj odtwarzanie co miesiąc. Szyfruj backupy kluczem innym niż produkcja.
• Certyfikaty SSL automatycznie odnawiane
  Let's Encrypt + Certbot lub Cloudflare. Alert na 30 dni przed wygaśnięciem. Wygasły certyfikat = niedostępna strona.

5. Security Headers & Konfiguracja serwera

• Content-Security-Policy (CSP)
  Definiuje skąd mogą być ładowane skrypty, style, obrazy. Blokuje XSS. Zacznij od report-only, potem enforce. Sprawdź: csp-evaluator.withgoogle.com.
• X-Frame-Options: DENY lub SAMEORIGIN
  Zapobiega clickjacking — osadzeniu strony w iframe na innej domenie.
• X-Content-Type-Options: nosniff
  Zapobiega MIME sniffing — przeglądarka nie "zgaduje" typu pliku.
• Referrer-Policy: strict-origin-when-cross-origin
  Kontroluje jakie informacje są wysyłane w nagłówku Referer.
• CORS poprawnie skonfigurowany
  Nigdy Access-Control-Allow-Origin: * na produkcji dla endpointów z autentykacją. Whitelist konkretnych domen.
• Komunikaty błędów nie ujawniają szczegółów technicznych
  Generic errors dla użytkowników ("Coś poszło nie tak"). Stack traces, nazwy tabel, wersje bibliotek — tylko w logach wewnętrznych.
• Debug mode i verbose logging wyłączone na produkcji
  NODE_ENV=production, DEBUG=false. Sprawdź czy żadne endpointy nie zwracają wewnętrznych danych w trybie debug.
• Ochrona przed CSRF (Cross-Site Request Forgery)
  CSRF token w formularzach lub SameSite=Strict cookies. Dotyczy operacji zmieniających stan (POST, PUT, DELETE).

6. Zależności & Supply Chain

• Zależności regularnie aktualizowane
  npm audit, pip-audit, Dependabot (GitHub). Krytyczne podatności: patch w ciągu 24h. Wysokie: w ciągu tygodnia.
• Używasz lock files (package-lock.json, yarn.lock, Pipfile.lock)
  Zapewnia deterministyczne instalacje. Commituj lock files do repo.
• Obrazy Docker bazują na oficjalnych, aktualnych wersjach
  Używaj konkretnych tagów (node:22-alpine), nie :latest. Skanuj obrazy (Trivy, Snyk).
• Subresource Integrity (SRI) dla zewnętrznych skryptów
  Jeśli ładujesz skrypty z CDN — dodaj integrity hash. Zapobiega atakom na łańcuch dostaw.

7. Monitoring, Logging & Incident Response

• Logowanie zdarzeń bezpieczeństwa
  Failed logins, permission denials, zmiany uprawnień, dostęp do wrażliwych danych, błędy autentykacji. Logi przechowuj min. 90 dni.
• Alerting na anomalie w czasie rzeczywistym
  Spike w failed logins (>50/min), dostęp z nowych krajów, masowe pobieranie danych. PagerDuty, OpsGenie, Grafana Alerting.
• Logi są niemodyfikowalne i centralnie przechowywane
  Atakujący po włamaniu często usuwa logi. Wysyłaj logi do zewnętrznego systemu (Datadog, Splunk, CloudWatch) w czasie rzeczywistym.
• Incident Response Plan (IRP) jest udokumentowany
  Kto jest powiadamiany? Jak izolujemy system? Jak komunikujemy się z użytkownikami? Jak przywracamy dane? Ćwicz IRP co 6 miesięcy.
• Penetration testing wykonany przed launch
  Przynajmniej OWASP ZAP (automatyczny) lub Burp Suite. Dla produktów z wrażliwymi danymi: zewnętrzny pentest przez certyfikowaną firmę.
• Vulnerability Disclosure Policy (VDP) opublikowana
  security.txt na stronie. Jak badacze bezpieczeństwa mogą zgłaszać podatności? Bez VDP — mogą opublikować bez ostrzeżenia.

8. RODO & Compliance

• Inwentaryzacja danych osobowych (Data Mapping)
  Co zbierasz, gdzie przechowujesz, jak długo, kto ma dostęp, z kim dzielisz. Wymagane przez RODO.
• Podstawa prawna przetwarzania danych
  Zgoda, umowa, uzasadniony interes, obowiązek prawny — każda kategoria danych musi mieć podstawę.
• Prawo do usunięcia danych (right to erasure)
  Użytkownik może zażądać usunięcia konta i wszystkich danych. Masz 30 dni na realizację.
• Powiadomienie o naruszeniu danych w ciągu 72h
  RODO wymaga powiadomienia UODO w ciągu 72h od wykrycia naruszenia. Masz procedurę?
• Umowy powierzenia danych z dostawcami (DPA)
  AWS, Google Cloud, Stripe, SendGrid — każdy przetwarza Twoje dane. Musisz mieć podpisane DPA.