Pięć pól, które zamieniają metadane w fakturę

Grzegorz GPS Świderski 25.09.2026

Jak państwo samo rozbroiło szyfrowanie w KSeF!

  To jest wpis o kluczowym przepisie dotyczącym KSeF, który czyni ten system na maksa szpiegowskim. To dzięki temu przepisowi swobodny dostęp do pełnej treści wszystkich faktur wystawianych w Polsce mają trzy obce wywiady: francuski, amerykański i izraelski.

  Rząd III RP w KSeF 2.0 nakazał zaszyfrować treść faktur, a potem sam wpisał do rozporządzenia, jak tę treść odszyfrować bez logowania. Wystarczy pięć pól z metadanych. Te same pięć pól, które zagraniczny pośrednik widzi na swojej bramce WAF po odszyfrowaniu ruchu do KSeF.

  Krajowy System e-Faktur pozwala pobrać pełną fakturę bez logowania, bez certyfikatu, bez tokenu i bez żadnego dowodu, że jest się stroną transakcji. Wystarczy znać pięć danych: numer KSeF, numer faktury, NIP lub inny identyfikator nabywcy, nazwę albo imię i nazwisko nabywcy oraz kwotę należności ogółem. Tak stanowi §8 rozporządzenia Ministra Finansów i Gospodarki z 12 grudnia 2025 w sprawie korzystania z KSeF (Dz.U. 2025 poz. 1815), wydanego na podstawie art. 106r ustawy o VAT.

  Rozporządzenie przewiduje dwa odrębne mechanizmy dostępu bez uwierzytelnienia. §7 opisuje dostęp dwuetapowy, związany z kodem umożliwiającym dostęp do faktury. §8 ustanawia osobny dostęp anonimowy, oparty wyłącznie na podaniu pięciu danych dotyczących dokumentu.

  W publicznym API 2.0 nie ma osobnego endpointu do anonimowego pobierania faktur. Funkcja nie zniknęła, tylko została pozostawiona w webowej Aplikacji Podatnika KSeF. Oficjalny podręcznik MF pokazuje funkcję „Anonimowe wyszukiwanie faktury”, wymagającą właśnie tych pięciu danych, która po odnalezieniu dokumentu umożliwia jego pobranie.

  Samo w sobie to słabe zabezpieczenie. W połączeniu z architekturą brzegową KSeF staje się czymś znacznie gorszym: wytrychem, który państwo wręczyło razem z kluczami do drzwi.

Po co ten mechanizm istnieje?

  Oficjalne uzasadnienie brzmi rozsądnie. Nie każdy nabywca loguje się do KSeF. Konsument, firma zagraniczna, klient na stacji paliw czy w sklepie dostaje fakturę albo potwierdzenie transakcji poza systemem i musi mieć jak sięgnąć po oryginał. Cel jest słuszny.

  Problem w tym, że do jego realizacji wybrano jedno z najsłabszych możliwych poświadczeń, a potem postawiono je obok zagranicznego pośrednika, który widzi wszystko, czego to poświadczenie wymaga.

Co ustaliłem o warstwie brzegowej KSeF?

  Moje audyty z lutego 2026 wykazały niezbicie, że ruch do wszystkich badanych domen KSeF, w tym produkcyjnego API 2.0 i Aplikacji Podatnika, przechodzi przez chmurowy WAF amerykańskiej firmy Imperva, należący do francuskiego koncernu zbrojeniowo-wywiadowczego Thales. Imperva terminuje połączenia TLS.

  Innymi słowy: szyfrowanie transportowe między Twoim programem księgowym a Ministerstwem Finansów kończy się u zagranicznego pośrednika. Dowody są dwa i żaden nie zostawia wiele miejsca na alternatywne wyjaśnienie.

  • Po pierwsze, odpowiedzi przesyłane wewnątrz połączenia HTTPS zawierają nagłówki i ciasteczka generowane przez Impervę: X-CDN: Imperva, X-Iinfo, visid_incap_, incap_ses_. Pośrednik, który tylko przepychałby zaszyfrowane pakiety, nie mógłby ich dopisać do treści HTTP.
  • Po drugie, żądania zawierające określone wzorce w treści są blokowane kodem 403 z sygnaturą polityki Impervy, także na ścieżkach, które w aplikacji nie istnieją, i także wtedy, gdy wzorzec leży głęboko w treści żądania. Żeby to zrobić, trzeba odczytać odszyfrowaną treść HTTP, zanim ruch zostanie przekazany dalej.

  Każdy może te testy powtórzyć. Polecenia są podane w raportach.

  Z dokumentacji API 2.0 i moich testów wynika następujący obraz tego, co Imperva widzi w postaci jawnej:

  • Wysyłka faktury: XML jest szyfrowany aplikacyjnie — AES-256, a klucz symetryczny zabezpieczony RSA-OAEP — więc Imperva nie widzi treści faktury.
  • Eksport paczek faktur: według dokumentacji również jest szyfrowany aplikacyjnie.
  • Pobranie pojedynczej faktury po numerze KSeF: XML jest chroniony wyłącznie przez TLS, więc po terminacji TLS jest jawny dla terminatora, czyli Impervy.
  • Zapytania o metadane: odpowiedzi JSON są jawne po terminacji TLS. Schemat InvoiceMetadata w specyfikacji API obejmuje m. in. numer faktury, numer KSeF, identyfikatory i nazwy podmiotów oraz kwoty faktury.
  • Nagłówki uwierzytelniające: tokeny dostępowe przesyłane przez klienta są widoczne dla pośrednika terminującego TLS.

  Anonimowy dostęp realizowany przez Aplikację Podatnika przechodzi przez tę samą warstwę brzegową.

Gdzie pięć pól zmienia rachunek ryzyka?

  W odpowiedziach na zapytania o metadane występują dane odpowiadające wszystkim pięciu polom wymaganym przez § 8. Tu jest sedno sprawy!!!

  Endpoint metadanych wymaga oczywiście uwierzytelnienia i odpowiednich uprawnień. Jednak nie o to chodzi. Pośrednik terminujący TLS nie musi się nigdzie logować. Widzi odpowiedzi na legalne zapytania wykonywane przez prawidłowo uwierzytelnione programy księgowe, biura rachunkowe i systemy ERP.

  Ministerstwo chwali się, że w KSeF 2.0 faktury są szyfrowane aplikacyjnie przy wysyłce i eksporcie, więc pośrednik nie widzi ich treści. To prawda — ale tylko do momentu, w którym przez warstwę brzegową przejdzie komplet metadanych wymaganych przez §8.

  Wtedy pośrednik dostaje pięć danych, które polskie prawo uznaje za wystarczające do anonimowego uzyskania pełnego dokumentu.

  Pięć pól działa więc jak most między metadanymi, które po terminacji TLS są dla warstwy brzegowej jawne, a treścią, którą dodatkowe szyfrowanie aplikacyjne miało przed takim pośrednikiem ukryć.

  Faktura może zostać wysłana w postaci zaszyfrowanej. Może zostać pobrana przez ERP w zaszyfrowanym eksporcie. Jednak jeżeli później w jawnej odpowiedzi metadanych przejdzie komplet danych wymaganych przez §8, istnieje druga droga do pełnej treści dokumentu.

  W tym sensie szyfrowanie treści faktur w KSeF 2.0 w dużej części okazuje się teatrem bezpieczeństwa: pancernymi drzwiami w ścianie z kartonu.

Drugi element to trwałość!

  Tokeny dostępowe wygasają, a pięciu danych z §8 nie ogranicza żaden termin ważności. Nie da się ich zmienić, zrotować ani unieważnić. Działają przez cały okres przechowywania faktury w KSeF, czyli co do zasady przez 10 lat od końca roku, w którym ją wystawiono.

  Wystarczy raz utrwalić te metadane, żeby zachować klucz do faktury na lata.

Dlaczego to słabe poświadczenie?

  Ściśle rzecz biorąc, nie jest to uwierzytelnienie osoby, lecz kontrola dostępu oparta na wiedzy o dokumencie. System nie pyta, kim jesteś. Pyta, czy znasz dane faktury.

  Tyle że te dane nie są i nigdy nie były tajne. Leżą w systemach ERP, raportach, mailach, systemach księgowych, kopiach zapasowych i logach. Nie da się ich zmienić ani unieważnić jak hasła czy tokenu. Ich ujawnienie może być trudne do odróżnienia od normalnego obiegu informacji biznesowej.

  Standardy bezpieczeństwa traktują mechanizmy oparte na wiedzy jako słabe dlatego, że informacja prywatna to nie to samo co informacja tajna.

  Państwo zrobiło hasło z danych, które krążą po całej gospodarce!!!

  Przypadkowy napastnik z zewnątrz nie zgadnie kompletu pięciu pól. Jednak to nie przypadkowy napastnik jest tu zagrożeniem.

  Zagrożeniem są ci, którzy metadane już mają: byli pracownicy, dostawcy usług, odbiorcy raportów, każdy, do kogo trafiły dane z wycieku, oraz pośrednicy techniczni w ruchu sieciowym.

  W przypadku KSeF ta ostatnia kategoria obejmuje operatora warstwy brzegowej, przez którą przechodzą metadane faktur z całej polskiej gospodarki. A więc zagraniczną firmę Imperva/Thales.

  Polskie państwo zbudowało w KSeF 2.0 szyfrowanie treści faktur, a jednocześnie samo stworzyło drugą drogę do tych samych dokumentów. Najpierw postawiło na brzegu systemu zagranicznego pośrednika, który terminuje TLS i widzi jawne metadane. Następnie wpisało do rozporządzenia, że właśnie zestaw takich metadanych wystarczy, by pobrać pełną fakturę bez uwierzytelnienia użytkownika.

  Każda z tych decyzji osobno budzi pytania. Razem tworzą mechanizm, w którym faktura, której komplet metadanych wymaganych przez §8 przeszedł przez warstwę brzegową, staje się dla podmiotu mającego dostęp do tej warstwy technicznie osiągalna w całości przez cały okres jej dostępności w KSeF — mimo że podczas wysyłki lub eksportu sam XML został poprawnie zaszyfrowany aplikacyjnie.

  W kolejnym odcinku opiszę, jak do tego doszło i kto podjął te decyzje. To będzie jeszcze ciekawsze, bo okazuje się, że za tymi pięcioma polami zagłosował cały Sejm i tylko jedna osoba była przeciw! Nie zgadniecie kto!

Grzegorz GPS Świderski
Twitter.com/gps65
t.me/KanalBlogeraGPS

PS. Wybór ostatnich artykułów o KSeF:

Tagi: GPS65, KSeF