WordPress 7.2 i klucze API: jak działa Secrets API?
WordPress 7.2 Beta 1 zapowiada Secrets API do bezpieczniejszego przechowywania kluczy i tokenów. Sprawdź, co zmieni się we wtyczkach WooCommerce i jak przygotować testy.

WordPress 7.2 wprowadza w wersji Beta 1 zapowiedziane Secrets API, czyli wspólny interfejs do przechowywania poufnych danych, takich jak klucze API i tokeny. Zamiast zapisywać je jako zwykłe opcje, wtyczka może korzystać z szyfrowanego magazynu i przewidzianych przez API operacji odczytu, zmiany oraz usuwania sekretów. Dla sklepu WooCommerce najważniejsza zmiana nie nastąpi jednak automatycznie: wtyczka integracji musi zostać dostosowana do tego interfejsu.
W skrócie: Secrets API daje twórcom wtyczek wspólny sposób obsługi sekretów i ma ograniczyć ryzyko ujawnienia ich przy odczycie bazy lub kopii zapasowej. Nie jest osobnym panelem do zarządzania kluczami, nie zmienia od razu sposobu działania każdej istniejącej integracji i nie chroni przed złośliwym kodem działającym w WordPressie. Beta 1 jest przeznaczona do testów, więc sprawdzaj ją poza sklepem produkcyjnym.
Co zmienia Secrets API w WordPressie 7.2?
Dotychczas wtyczki często zapisywały klucze i tokeny jako wartości w tabeli opcji WordPressa. Propozycja API opisuje standardowe funkcje do ustawiania, odczytu, usuwania i importowania sekretów. W WordPressie 7.2 Beta 1 projekt przedstawia Secrets API jako interfejs dla deweloperów, a oficjalny poradnik testowania bety wymienia też obsługę przez WP-CLI i szyfrowanie libsodium. Zapowiedź bety WordPress 7.2 i instrukcje testowania Secrets API opisują funkcję jako nowość dla twórców i osób testujących.
W propozycji funkcja odczytu może zwrócić sekret, informację, że go nie ma, albo błąd, gdy nie da się go odszyfrować. To rozróżnienie ma znaczenie dla integracji: brak klucza może uruchomić proces podłączania usługi, a błąd odszyfrowania powinien skłonić do sprawdzenia konfiguracji lub ponownego wprowadzenia danych. Wartość sekretu ma być ujawniana jawnie dopiero w miejscu, w którym wtyczka jej potrzebuje. Opis interfejsu i jego zachowania przedstawia te funkcje oraz rozróżnienie między brakiem sekretu a problemem z jego odczytem.
| Sposób przechowywania | Co widzi osoba przeglądająca bazę | Co musi zrobić właściciel sklepu |
|---|---|---|
| Zwykła opcja wtyczki | Jeśli wtyczka zapisuje wartość jawnym tekstem, może być czytelna w zrzucie bazy | Sprawdzić, czy wtyczka zmieniła sposób zapisu i czy klucz nie pozostał w starej opcji |
| Secrets API | Wartość jest przechowywana jako zaszyfrowany sekret, zgodnie z założeniami interfejsu | Użyć zgodnej wersji wtyczki i sprawdzić integrację na środowisku testowym |
| Sekret w zewnętrznym magazynie | Zależy od dostawcy i konfiguracji magazynu | Uzgodnić obsługę z dostawcą hostingu lub integracji |
Tabela opisuje różnice na poziomie sposobu przechowywania, a nie gwarancję bezpieczeństwa całego sklepu. API nie zastępuje aktualizacji wtyczek, kontroli dostępu ani ochrony serwera.
Co szyfrowanie daje, a czego nie rozwiązuje?
Szyfrowanie w spoczynku utrudnia odczytanie klucza z samego zrzutu bazy lub kopii, jeśli osoba, która je pozyskała, nie ma materiału potrzebnego do odszyfrowania. Propozycja opisuje domyślny magazyn oparty na API opcji WordPressa, w którym sekrety są zapisane jako zaszyfrowane dane, a także możliwość podmiany dostawcy magazynu. Projekt API opisuje szyfrowanie, źródło klucza i możliwość użycia innego dostawcy.
To nie jest izolacja jednej wtyczki od drugiej. Kod działający wewnątrz WordPressa może wywołać API i uzyskać sekret, jeśli ma do niego dostęp w działającym środowisku. Autor propozycji wprost wskazuje, że interfejs nie zabezpiecza przed wykonaniem złośliwego kodu w procesie WordPressa i nie zapewnia odrębnych uprawnień dla każdej wtyczki. Dlatego nadal potrzebujesz aktualizacji, przeglądu używanych rozszerzeń i ograniczenia dostępu do panelu oraz serwera.
Szyfrowanie wprowadza też obowiązki przy zmianach konfiguracji. Propozycja opisuje wykorzystanie dedykowanego źródła klucza lub wartości pochodnych od istniejących soli WordPressa; jeśli materiał potrzebny do odszyfrowania zostanie utracony, sekret może przestać być dostępny i trzeba będzie wprowadzić go ponownie. Przed zmianą soli, migracją hostingu lub odtworzeniem kopii sprawdź zalecenia dla konkretnej wersji API i wtyczki.
Co oznacza to dla wtyczek WooCommerce?
Secrets API nie przenosi automatycznie kluczy z każdej wtyczki płatniczej, wysyłkowej, SMTP czy analitycznej. To autor rozszerzenia musi zdecydować o obsłudze interfejsu i przygotować aktualizację. Do tego czasu klucz może nadal być przechowywany dotychczasowym sposobem.
Przed wdrożeniem sprawdź w dokumentacji lub u autora rozszerzenia:
- czy wtyczka korzysta z Secrets API w aktualnej wersji;
- czy istniejące klucze są importowane, czy trzeba je podać ponownie;
- jak wtyczka zachowuje się, gdy sekretu brakuje albo nie można go odszyfrować;
- jak przeprowadzić zmianę klucza i czy wymaga ona ponownego połączenia usługi.
Propozycja interfejsu zawiera funkcję importu opcji do sekretu, ale jej obecność nie oznacza, że każda wtyczka automatycznie migruje własne dane. Potwierdź zakres migracji w dokumentacji konkretnej integracji.
Jak przygotować sklep do testów?
Poniższa procedura obejmuje test sklepu z WooCommerce 10.8 jako wersją referencyjną. Dokumentacja WooCommerce podaje dla tej wersji minimalnie WordPress 6.9 i PHP 7.4; spełnienie tych wymagań nie potwierdza zgodności WooCommerce 10.8 z WordPress 7.2 Beta 1.
WordPress opublikował Beta 1 20 października 2026 r. W komunikacie wydania zaznacza, że wersja beta służy do testów i rozwoju, a nie do uruchamiania witryn produkcyjnych lub krytycznych. Komunikat WordPressa o Beta 1 podaje również sposoby testowania, w tym lokalne środowisko, WordPress Playground i WP-CLI. Fakty sprawdziłem 26 października 2026 r.
- Zrób spis integracji i sekretów. Zanotuj, które wtyczki łączą sklep z usługami zewnętrznymi oraz gdzie konfigurujesz ich klucze. Nie wklejaj samych wartości do dokumentu testowego.
- Utwórz kopię testową i zapisz wersje. Odtwórz na niej typowe scenariusze sklepu: połączenie integracji, zapis ustawień, odświeżenie strony konfiguracji i testowe wywołanie usługi. Nie używaj do testów produkcyjnych kluczy z uprawnieniami do rzeczywistych operacji. W panelu przejdź do WooCommerce > Status > WordPress environment i zapisz wartości z wierszy wersji WooCommerce oraz WordPressa. To miejsce wskazuje dokumentacja sprawdzania wersji WooCommerce. Zapisz też, że procedura dotyczy WooCommerce 10.8; jego wymagania minimalne nie rozstrzygają zgodności z betą WordPressa.
- Zainstaluj betę wyłącznie na środowisku testowym. Oficjalny komunikat pokazuje między innymi polecenie
wp core update --version=7.2-beta1; uruchamiaj je z katalogu instalacji testowej, nie produkcyjnej. - Sprawdź komunikaty i ujawnianie danych. Zespół testowy WordPressa proponuje sprawdzenie stanu w Narzędzia → Stan witryny oraz zweryfikowanie, czy sekrety nie trafiają jawnie do bazy, REST API, logów, informacji o stanie witryny i eksportu XML. Porównaj obserwacje z listą kontrolną testów Secrets API.
- Zleć deweloperowi test scenariuszy sekretu. Oficjalna lista testów zaleca rejestrację i odczyt poświadczeń przez funkcje pomocnicze Secrets API w kodzie testowym lub WP-CLI oraz sprawdzenie nieprawidłowych wywołań. Poproś o sprawdzenie trzech wyników odczytu: poprawnie odczytanego sekretu, braku wartości oraz błędu odczytu, gdy sekret istnieje, ale nie da się go odszyfrować. Zgodnie z opisem API brak sekretu powinien być rozpoznany jako brak, a problem z odczytem jako błąd; nieprawidłowe wywołania powinny kończyć się obsłużonym błędem bez błędu krytycznego. Po próbie deweloper powinien usunąć testowy sekret.
- Ustal plan aktualizacji z autorami wtyczek. Przed aktualizacją produkcji sprawdź, czy używane rozszerzenia deklarują zgodność z docelową wersją WordPressa i jak obsługują migrację sekretów.
Zespół testowy opisuje te kontrole w liście testów dla WordPressa 7.2. Jeśli testujesz sklep, możesz też skorzystać z poradnika o testowaniu WooCommerce przed betą WordPressa 7.2, który obejmuje szerszą kontrolę zgodności sklepu.
Przepływ weryfikacji
flowchart TD
A[Spis integracji] --> B[Kopia testowa]
B --> C[Beta WordPressa]
C --> D[Test zapisu i odczytu]
D --> E[Kontrola logów i eksportów]
E --> F[Potwierdzenie zgodności wtyczek]
F --> G[Plan aktualizacji sklepu]FAQ
Czy WordPress 7.2 automatycznie zaszyfruje klucze zapisane przez wtyczki?
Nie zakładaj automatycznej migracji. Wtyczka musi obsługiwać Secrets API lub przeprowadzić własny import danych. Sprawdź instrukcję autora rozszerzenia i ustal, czy po aktualizacji klucz trzeba wprowadzić ponownie.
Czy Secrets API będzie miało ekran do zarządzania wszystkimi kluczami?
Propozycja dla WordPressa 7.2 zakłada API oraz obsługę WP-CLI, a osobny ekran administracyjny odkłada na później. W poradniku testowym wymieniono jednak kontrole Secrets API w narzędziu Stan witryny. To nie jest równoznaczne z panelem do przeglądania i edytowania wartości kluczy.
Czy szyfrowane klucze są bezpieczne, jeśli ktoś przejmie sklep?
Szyfrowanie bazy pomaga, gdy ktoś uzyska sam zrzut danych bez dostępu do działającego WordPressa. Nie chroni przed złośliwym kodem, który działa już w witrynie i może wywołać funkcję odczytu sekretu.
Czy mogę testować WordPressa 7.2 Beta 1 na sklepie produkcyjnym?
Nie. WordPress przeznacza tę wersję do testów i rozwoju oraz odradza instalowanie jej na witrynach produkcyjnych i krytycznych. Skorzystaj z lokalnego środowiska lub kopii testowej.
Co dalej
Zacznij od testu sklepu WooCommerce przed betą WordPressa 7.2, a potem sprawdź u autorów używanych wtyczek, kiedy udostępnią zgodność z Secrets API.
