Zbudowałeś landing sam (HTML + CSS + JS) i oszczędziłeś pieniądze. Teraz chcesz sprawdzić, czy nie ma prostych błędów, które kończą się wyciekiem danych, podmianą skryptów, spamem na webhooku albo ostrzeżeniami w przeglądarce. Ten artykuł daje Ci jeden prompt do pre-audytu: wyłapie typowe wpadki i powie, co zrobisz sam, a co oddać do IT.
Ważne: to nie jest audyt bezpieczeństwa ani testy penetracyjne. AI nie widzi Twoich realnych nagłówków HTTP, DNS, konfiguracji serwera, WAF, rate limiting, ani zachowania strony w runtime, jeśli mu tego nie dostarczysz. Traktuj wynik jako checklistę ryzyk i listę zadań. Konsultacja z profesjonalistą jest bardziej niż wskazana!
Kiedy użyć
- Przed puszczeniem ruchu z reklam, sociali, newslettera, PR.
- Gdy masz formularz, webhook, zapis do newslettera, kalendarz, chat, analitykę.
- Gdy używasz zewnętrznych skryptów (CDN, widgety, tracking) i nie wiesz, co to zmienia.
- Gdy landing jest statyczny, ale stoi na hostingu, którego ustawień nie rozumiesz.
- Gdy ktoś mówi „ustaw CSP i nagłówki”, a Ty potrzebujesz gotowca i priorytetów.
- Gdy podejrzewasz, że coś jest nie tak (dziwne przekierowania, nieznane skrypty, ostrzeżenia w Google/Chrome).
Co przygotować przed użyciem
Zbierz to i wklej do promptu. Bez tego AI będzie zgadywać.
- Link do strony produkcyjnej (i ewentualnie staging).
- Fragmenty kodu:
<head>, wszystkie<script src=...>, formularze,fetch(), miejsca zinnerHTML. - Lista integracji: analytics, pixel, chat, mapy, wideo, CDN, Calendly itp.
- Gdzie idą dane z formularza: mail, CRM, webhook (Make/Zapier), własny backend.
- Zrzut nagłówków HTTP: wynik
curl -I https://twojadomena.pllub screen z DevTools → Network → Headers. - Wynik szybkich testów DIY (wystarczy wkleić notatki): SecurityHeaders, Mozilla Observatory, SSL Labs (TLS).
- Kto ma dostępy do domeny/DNS, hostingu, repo, kont analitycznych.
Zasady dobrego promptowania w tym przypadku
- To ma być pre-audit: celem jest zredukować ryzyko oczywistych wpadek, nie „udowodnić bezpieczeństwo”.
- Wymuś oznaczanie braków: wszystko, czego nie da się potwierdzić z danych, ma mieć tag [WYMAGA WERYFIKACJI].
- Nie proś o fakty bez danych. Jeśli nie wkleisz nagłówków HTTP, model nie ma prawa ich znać.
- Daj kontekst biznesowy, bo priorytety zależą od stawki: czy to leadgen, płatności, kampania, czy portfolio.
Pamiętaj, czego AI nie wykryje bez dodatkowych danych:
- konfiguracji DNS (np. przejęcie domeny), TLS, HSTS na realnym serwerze
- CORS, rate limiting, WAF, reguł firewall, logów, monitoringu
- podatności w usługach po drugiej stronie webhooka
- problemów wynikających z runtime (dziwne redirecty, wstrzyknięcia w zależnościach)
- Wymagaj wyniku w formie: ryzyko → scenariusz nadużycia → szybka poprawka → kto robi.
- Dodaj limit czasu: jeśli lista zadań przekracza Twój limit, prompt ma powiedzieć „deleguj”.
Gotowy prompt (do skopiowania)
Zmienne i jak je wypełnić:
- {{url}}: adres strony.
- {{technologia}}: hosting/stack (np. Netlify, Cloudflare Pages, Vercel/Next.js, VPS+Nginx).
- {{cel_strony}}: 1 zdanie (generowanie leadów, zapis na konsultację, sprzedaż, portfolio).
- {{wartość_ryzyka}}: „niska/średnia/wysoka” + jedno zdanie dlaczego (np. „płatny ruch i CRM”).
- {{integracje}}: lista zewnętrznych usług i skryptów.
- {{formularz_backend}}: gdzie trafiają dane, jaką drogą.
- {{nagłówki_http}}: wklej wynik
curl -Ialbo nagłówki z DevTools. - {{wyniki_testów}}: krótkie notatki z SecurityHeaders / Observatory / SSL Labs.
- {{kod_html}}, {{kod_js}}, {{kod_css}}: fragmenty, nie musisz wklejać wszystkiego.
- {{poziom_techniczny}}: „nietech/średni/dev”.
- {{limit_czasu}}: ile czasu chcesz maks poświęcić (np. „2h”, „1 dzień”).
- {{ton}}: np. „krótko i stanowczo”.
Jesteś konsultantem web security dla małych firm. Twoje zadanie: zrobić PRE-AUDYT landing page i wyłapać typowe wpadki. To nie jest pełny audyt ani pentest.
Kontekst:
- URL: {{url}}
- Stack/hosting: {{technologia}}
- Cel strony: {{cel_strony}}
- Wartość ryzyka: {{wartość_ryzyka}}
- Integracje: {{integracje}}
- Formularz/backend: {{formularz_backend}}
- Limit czasu na poprawki: {{limit_czasu}}
- Poziom techniczny odbiorcy: {{poziom_techniczny}}
- Ton: {{ton}}
Twarde dane (jeśli brak, oznacz to jako [WYMAGA WERYFIKACJI]):
- Nagłówki HTTP (curl -I lub DevTools):
{{nagłówki_http}}
- Wyniki szybkich testów (SecurityHeaders / Mozilla Observatory / SSL Labs):
{{wyniki_testów}}
Kod / fragmenty:
- HTML (head + formularze + skrypty):
{{kod_html}}
- JS (fetch, formularz, dynamiczne wstawianie HTML, integracje):
{{kod_js}}
- CSS (importy, zewnętrzne zasoby):
{{kod_css}}
Wynik przygotuj w 7 sekcjach:
1) Szybki werdykt (max 6 zdań):
- Czy są czerwone flagi przed publikacją?
- Co jest [WYMAGA WERYFIKACJI] i bez czego nie wolno ogłaszać “bezpieczne”?
2) TOP 10 ryzyk (tabela):
- Ryzyko
- Scenariusz nadużycia (1–2 zdania)
- Priorytet (High/Medium/Low) z uzasadnieniem opartym o {{wartość_ryzyka}}
- Dowód: “kod / nagłówki / test” albo [WYMAGA WERYFIKACJI]
- Najszybsza poprawka (konkretnie)
- Kto to robi (ja / IT / hosting / vendor)
3) Must-have przed puszczeniem ruchu (checklista max 12 punktów).
- Jeśli coś jest krytyczne: oznacz jako MUST.
4) Konkretne rekomendacje techniczne:
- Nagłówki bezpieczeństwa (CSP, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- Zasady dot. skryptów zewnętrznych: SRI, self-hosting, ograniczenie domen
- Formularze/webhook: antyspam + rate limiting + alerty kosztowe (jeśli Make/Zapier)
5) Testy DIY (bez płatnych narzędzi):
- Jak sprawdzić nagłówki (curl/DevTools)
- Jak sprawdzić TLS (SSL Labs)
- Jak sprawdzić CSP (CSP Evaluator) i jak zacząć od Report-Only
6) Co AI NIE wykryje na podstawie tych danych (lista) + co dostarczyć, żeby to ocenić.
7) Plan awaryjny “30 minut”, jeśli coś poszło nie tak:
- Najpierw: co odciąć / zmienić
- Potem: co sprawdzić
- Na koniec: co przywrócić i jak monitorować
Nie wymyślaj. Jeśli nie masz danych, pisz [WYMAGA WERYFIKACJI] i podaj najprostszy sposób weryfikacji.
Na końcu dodaj 5 pytań, które mam zadać IT/hostingowi, jeśli chcę to delegować.Przykład użycia
Wypełnione zmienne (skrót):
- {{url}}:
https://twojafirma.pl - {{stack}}: „Cloudflare Pages”
- {{cel_strony}}: „landing do zapisu na konsultację”
- {{wartość_ryzyka}}: „wysoka: płatny ruch + CRM”
- {{integracje}}: „analytics, osadzony kalendarz, widget czatu”
- {{formularz_backend}}: „formularz wysyła dane do webhooka (Make)”
- {{headers_http}}: „(wklejone z curl -I)… brak HSTS…”
- {{kod_js}}:
fetch("https://hook…")+ użycieinnerHTML
Przykładowy wynik (fragment, skrócony):
- Werdykt: strona może działać, ale są 2 czerwone flagi: webhook bez ochrony antyspam i brak potwierdzonego HSTS. Część rzeczy oznaczam jako [WYMAGA WERYFIKACJI], bo nie mam pełnych nagłówków i wyniku testów TLS.
- High: formularz → webhook bez rate limiting i bez antyspamu. Skutek: nie tylko spam, ale ryzyko kosztów po stronie automatyzacji i zablokowania usług. MUST: honeypot/Turnstile + limit żądań + alert.
- Medium: zewnętrzne skrypty bez ograniczeń w CSP. MUST: zacząć od
Content-Security-Policy-Report-Only, zebrać raporty, potem zaostrzyć. - Testy DIY: uruchom DevTools → Security/Network, sprawdź
Strict-Transport-Security, użyj SSL Labs do oceny TLS, użyj CSP Evaluator do sanity-check polityki. - Plan awaryjny 30 min: odłącz webhook, zmień tokeny/dostępy, usuń nieznane skrypty, sprawdź ostatnie deploye, poproś hosting o logi.
Najczęstsze błędy i poprawki (min. 5)
Traktowanie wyniku z AI jak audytu
Poprawka: nazywaj to pre-audytem. Każdą rzecz bez danych oznaczaj [WYMAGA WERYFIKACJI]. Dopiero nagłówki + testy + logi dają obraz.Brak realnych nagłówków HTTP w danych wejściowych
Poprawka: zawsze doklejcurl -Ialbo nagłówki z DevTools. Bez tego nie ma rozmowy o CSP/HSTS „na serio”.Webhook/formularz bez limitów = ryzyko finansowe i reputacyjne
Poprawka: MUST: antyspam (honeypot/Turnstile), rate limiting po stronie endpointu, limity i alerty po stronie automatyzacji (Make/Zapier), logowanie odrzuceń.CSP włączone bez testu
Poprawka: zacznij odContent-Security-Policy-Report-Only, zbierz naruszenia, dopiero potem egzekwuj. Inaczej sam się „wyłączysz” w produkcji.innerHTMLi dynamiczne składanie HTML z danych
Poprawka: używajtextContent, szablonów bez interpretacji HTML, albo sanitizacji (świadomie). W prompt wrzucaj konkretne fragmenty kodu.Sekrety w JS / publiczne tokeny udające prywatne
Poprawka: wszystko w przeglądarce jest publiczne. Sekrety przenieś do backendu lub użyj kluczy przeznaczonych do frontu.Brak planu awaryjnego
Poprawka: miej „checklistę 30 minut”: odłącz webhook, wstrzymaj deploy, zmień hasła i tokeny, porównaj pliki z repo, sprawdź alerty, dopiero potem przywracaj.
Warianty promptu
Krótki dla początkujących
Zrób PRE-AUDYT bezpieczeństwa mojego landing page. Wypisz 10 najważniejszych poprawek.
URL: {{url}}
Stack: {{technologia}}
Cel: {{cel_strony}}
Wartość ryzyka: {{wartość_ryzyka}}
Integracje: {{integracje}}
Formularz/backend: {{formularz_backend}}
Nagłówki HTTP (curl -I / DevTools): {{nagłówki_http}}
Kod (najważniejsze fragmenty): {{kod_html}} {{kod_js}}
Zasady:
- Nie wymyślaj. Braki oznacz jako [WYMAGA WERYFIKACJI].
- Daj listę: problem → dlaczego groźne → co zrobić dziś → ja czy IT.
- Dodaj 5 testów DIY, które mogę wykonać od razu.Precyzyjny
Zrób PRE-AUDYT bezpieczeństwa landing page i ułóż plan prac.
Dane: {{url}}, {{technologia}}, {{cel_strony}}, {{wartość_ryzyka}}, {{integracje}}, {{formularz_backend}}.
Nagłówki HTTP: {{nagłówki_http}}
Wyniki testów: {{wyniki_testów}}
Kod: {{kod_html}} {{kod_js}}
Wymagam:
1) TOP 10 ryzyk z priorytetem zależnym od {{wartość_ryzyka}} i z kolumną “Dowód” (kod/nagłówki/test/[WYMAGA WERYFIKACJI]).
2) Must-have przed publikacją (max 12).
3) Gotowe snippety nagłówków dla {{stack}} albo oznaczenie [WYMAGA WERYFIKACJI], jeśli nie da się.
4) Sekcja “Co AI nie oceni bez dodatkowych danych” + lista pytań do hostingu.
5) Plan awaryjny 30 min po incydencie.Następny krok
Powiązane: Prompt do SEO dla przedsiębiorców