Headless WordPress и сигурността, какво всъщност се променя

# ЕтикетиHeadlessСигурност

Екипът на WPhost10 окт 202615 мин четене

Ако обмисляте headless магазин, вероятно сте чули, че е „по-сигурен“. Отчасти е вярно. Headless WordPress наистина променя сигурността, защото публичната част на сайта вече не е WordPress, но не решава въпроса със сигурността веднъж завинаги. Някои рискове намаляват, а към останалите се добавят рисковете на една нова система.

В това ръководство разделяме честно двете страни. Първо разглеждаме какво наистина се променя, после какво остава същото, а накрая уязвимостите на самия Next.js и тайните ключове, които свързват двете части. Чеклистът в края ще Ви помогне да проверите сегашния си сайт или да зададете правилните въпроси на изпълнителя.

Накратко

При headless посетителите виждат приложение на Next.js, а WordPress остава за съдържанието и поръчките.
Админ панелът и API на WordPress могат да са достъпни само от определени адреси, през шлюз за достъп или през VPN.
WordPress и плъгините пак трябва да се обновяват, а REST API може да показва повече, отколкото искате.
Next.js и npm пакетите имат свои уязвимости. През 2025 г. две от тях бяха критични.
Тайните ключове стоят само на сървъра, а обновленията и наблюдението покриват двете части.

Какво е headless WordPress, накратко

При класическия WordPress една система прави всичко. Тя пази съдържанието и при всяко посещение сглобява страниците с PHP, а в нея е и админ панелът. При headless тези роли се разделят. Публичната част е отделно приложение, при нас на Next.js, което взема съдържанието от WordPress през API (програмен интерфейс, през който двете системи обменят данни) и подготвя страниците предварително. WordPress остава за управлението, а в магазина WooCommerce продължава да пази продуктите и поръчките.

Кога този модел си струва и кога не, е описано в ръководството за headless WordPress с Next.js. Тук ни интересува само сигурността.

Какво наистина се променя

Посетителите не стигат до WordPress

Страниците на headless сайта обикновено са подготвени предварително, затова при отварянето им PHP и базата данни на WordPress не работят за всеки посетител. Темата на WordPress не се показва никъде, а плъгините за публичната част, като конструктори на страници и слайдъри, вече не са нужни, защото страниците се правят в Next.js. Изтрийте ги. Плъгин, който го няма, не може да има уязвимост.

Тук има важна подробност. Докато плъгинът е инсталиран и WordPress е достъпен от интернет, кодът му може да бъде извикан директно на адреса на WordPress, дори публичният сайт да не го ползва. Затова истинската полза идва, когато махнете излишния код и ограничите кой стига до WordPress.

Админ панелът и API могат да се скрият

Посетителите вече не отварят WordPress, затова той не е длъжен да е достъпен за целия интернет. Обичайните начини да го ограничите са три.

Списък с разрешени адреси. Сървърът приема заявки към WordPress само от IP адресите на сървъра с Next.js и на офиса.
Шлюз за достъп. Всяка заявка към админ панела минава първо през услуга, която иска вход с фирмен акаунт и, по желание, втори фактор.
VPN. Редакторите се свързват към частна мрежа и едва оттам отварят админ панела.

Важно е какво точно затваряте. Сървърът с Next.js трябва да стига до API на WordPress, за да взема съдържание, а редакторите трябва да стигат до админ панела. Ако браузърът на купувача говори директно с WooCommerce, например за количката, тези адреси остават публични. Store API на WooCommerce е направен точно за това и работи без вход. Когато количката и поръчките минават през сървъра на Next.js, WordPress може да е затворен за всички останали.

WordPress сам препоръчва допълнителна парола на ниво сървър за /wp-admin/ като втори слой и предупреждава, че тя може да счупи функциите, които разчитат на admin-ajax.php. При headless публичният сайт не ги ползва, така че този риск е много по-малък. При headless магазините, които правим, админ панелът може да е скрит от интернет, а доколко точно, зависи от това как работят редакторите и външните услуги, които изпращат данни към WordPress.

XML-RPC може да се затвори напълно

XML-RPC е стар интерфейс на WordPress, който Next.js не ползва. В класически сайт понякога остава заради Jetpack или мобилни приложения за публикуване, но при headless можете да затворите файла xmlrpc.php на сървъра, както е показано в ръководството за защита на WordPress сайт. Филтърът xmlrpc_enabled в WordPress не стига, защото спира само методите, които изискват вход.

Какво не се променя

WordPress и плъгините пак трябва да се обновяват

Headless не прави WordPress неуязвим. Според годишния доклад на Patchstack през 2025 г. в екосистемата на WordPress са открити 11 334 нови уязвимости, 91% от тях в плъгини и 9% в теми, а в ядрото само 6. В headless магазина плъгините са по-малко, но остават WooCommerce и плъгините, от които магазинът наистина има нужда, например за фактури или за куриерите.

Скритият админ панел намалява риска, защото нападателят не стига до уязвимия код, но не го премахва. Данните от витрината, например поръчка с адрес за доставка, пак влизат в WooCommerce и минават през кода на плъгините. Редактор с открадната парола, който влиза от разрешен адрес или през VPN, също стига до админ панела. Затова обновленията остават най-важната защита и при headless. Обновявайте WordPress и плъгините навреме, след проверка в staging.

REST API показва повече, отколкото очаквате

REST API е начинът, по който Next.js чете съдържанието от WordPress. По замисъл това е отворен интерфейс, който показва публикуваното съдържание на всеки, който го поиска. Това е нормално, но има две подробности.

Първата е списъкът с потребители. Адресът /wp-json/wp/v2/users показва на всеки, без вход, потребителите с публикувано съдържание, с име и slug. WordPress прави slug-а от потребителското име при създаването на профила, затова той обикновено издава името за вход.

Втората са плъгините. Всеки плъгин може да добави свои адреси в API. От версия 5.5 WordPress предупреждава разработчика, когато адрес е регистриран без проверка на правата, но предупреждението не спира адреса и той остава публичен.

Изключването на REST API не е решение, защото WordPress го ползва и в админ панела, а при headless без него сайтът няма откъде да взема съдържание. Ограничете кой стига до API, ако витрината може да го чете от сървъра, или затворете отделните адреси, които не са нужни. Проверете какво вижда непознат с две команди, които само четат.

Bash

# Вашият компютър, извън офиса и без VPN. Само четат.
curl -s --max-time 10 https://cms.primer.bg/wp-json/wp/v2/users \
  | head -c 300; echo
curl -s -o /dev/null --max-time 10 -w '%{http_code}\n' \
  https://cms.primer.bg/wp-login.php

Заменете cms.primer.bg с адреса, на който работи WordPress. Ако първата команда покаже списък с имена и slug, всеки може да чете API. Ако втората върне 200, страницата за вход е достъпна от интернет. При ограничен достъп ще видите 401 или 403, а 000 означава, че сървърът изобщо не е отговорил, което също е добър знак.

Next.js има свои уязвимости

Витрината на Next.js е код, който работи на сървър, и като всеки код има уязвимости. Две от тях през 2025 г. бяха критични и показват защо и тази част се нуждае от редовни обновления.

CVE-2025-29927, заобикаляне на проверките в middleware

На 21 март 2025 г. беше публикувана уязвимост в Next.js с оценка 9,1 по CVSS, тоест критична. Проверките за достъп, сложени в middleware (код, който се изпълнява преди страниците), можеха да бъдат заобиколени с една специална заглавка в заявката. Засегнати бяха версиите от 11.1.4 нататък до поправените 12.3.5, 13.5.9, 14.2.25 и 15.2.3. Уязвими бяха приложенията на собствен сървър, пуснати с next start или с output: 'standalone', а статично експортираните сайтове не бяха.

Поуката е по-широка от самата грешка. Next.js вече изрично съветва проверките за вход и права да се правят във всяка функция, която променя данни, вместо да се разчита само на middleware. От версия 16 middleware се казва proxy.

CVE-2025-55182, изпълнение на чужд код през React Server Components

На 3 декември 2025 г. екипът на React обяви уязвимост с максималната оценка 10 по CVSS. Специално подготвена заявка можеше да накара сървъра да изпълни код на нападателя, без никакъв вход. Проблемът беше в React Server Components, версии 19.0.0, 19.1.0, 19.1.1 и 19.2.0, а поправката излезе във версии 19.0.1, 19.1.2 и 19.2.1. Два дни по-късно американската агенция за киберсигурност CISA я добави в каталога си с уязвимости, които вече се използват в атаки.

В Next.js бяха засегнати приложенията с App Router на версии 15 и 16, а Next.js 13, стабилната версия 14 и приложенията с Pages Router не бяха. Заобиколно решение нямаше, само обновяване. По-късно излязоха поправки и за свързани уязвимости, затова днес целта е последната версия от Вашия клон на Next.js. След обновяването Next.js препоръча да се сменят и всички тайни ключове на приложенията, които са били онлайн и необновени към 4 декември.

npm пакетите

Освен от Next.js и React приложението зависи от много други пакети от npm, регистъра на пакети за JavaScript. Уязвимост в който и да е от тях е уязвимост и в магазина. Двете команди по-долу показват версиите и известните уязвимости. Пуснете ги в папката на проекта или помолете разработчика да Ви изпрати резултата.

Bash

# В папката на проекта с Next.js. Не променят файловете.
npm ls next react
npm audit --omit=dev

Втората изпраща списъка с пакетите към регистъра на npm и връща известните уязвимости в тях. Не пускайте npm audit fix --force без проверка, защото може да вдигне пакет до нова основна версия, която чупи приложението. Ако кодът е в GitHub, включете Dependabot alerts, за да получавате предупреждение, когато пакет има известна уязвимост.

Следете и коя основна версия на Next.js ползвате. Поправки за сигурност получават само текущата и предишната основна версия, всяка до две години след излизането си. Според политиката на Next.js версия 14 и по-старите вече не се поддържат, а поправки за тях излизат само по изключение.

Тайните, които свързват двете части

Двете части на headless сайта трябва да си вярват, затова между тях има тайни ключове. Такъв е ключът за REST API на WooCommerce, с който витрината създава поръчки, или паролата за приложение (Application Password) в WordPress. Който има тези ключове, може да прави всичко, което прави витрината.

Тайните стоят само на сървъра. В Next.js променливите на средата, които започват с NEXT_PUBLIC_, се вграждат в кода, който отива в браузъра, и всеки може да ги прочете. Ключовете за WordPress и WooCommerce никога не бива да са с такова име.
Файловете .env не влизат в Git. Next.js предупреждава, че почти никога не искате да ги качвате в хранилището, а шаблонът на create-next-app ги изключва по подразбиране.
Всеки ключ има само нужните права. WooCommerce прави ключове с права Read, Write или Read/Write, а ключ, който само чете продукти, не бива да може да пише. Тайната част на ключа се показва само веднъж, затова я запишете направо там, където сървърът пази тайните.
Ключовете се сменят бързо. Когато човек напусне екипа или ключ изтече някъде, смяната трябва да отнема минути и да не спира магазина. Понякога я препоръчва и производителят, както Next.js след CVE-2025-55182.

Обновления и наблюдение от двете страни

При класическия сайт обновявате една система. При headless системите са две и всяка има свой ритъм.

WordPress. Ядрото, плъгините и темата. WordPress сам инсталира малките версии на ядрото от 3.7 насам, но плъгините и темата чакат Вас или поддръжката.
Next.js и npm. Самият Next.js, React и останалите пакети. Тук обновлението изисква нова компилация и ново пускане на приложението, а бутон в админ панела няма.

И при двете промяната трябва да мине през Git и staging, преди да стигне до живия сайт, с план за връщане назад.

Наблюдението също трябва да покрива двете части. Следете дали витрината отговаря, дали API на WordPress отговаря на сървъра на Next.js, колко неуспешни опита за вход има в админ панела и дали има грешки при създаването на поръчки. Ако WooCommerce спре да отговаря, витрината може да продължи да показва страници от кеша и проблемът да остане незабелязан. При нашия модел поръчките чакат в опашка и не се губят, но и тогава наблюдението трябва да хване проблема навреме.

Бекъпите остават задължителни. Базата на WordPress пази продуктите и поръчките, а кодът на витрината е в Git. Как се прави и проверява бекъп, е описано в ръководството за бекъп на WordPress.

Чеклист

Ненужните плъгини за публичната част са изтрити от WordPress.
Админ панелът и API на WordPress са достъпни само за сървъра на Next.js и за редакторите, или е записано защо не са.
xmlrpc.php е затворен на сървъра.
/wp-json/wp/v2/users не показва списък на потребителите на непознати.
WordPress и плъгините се обновяват навреме след проверка в staging.
Next.js е на поддържана основна версия и на последната поправка от своя клон.
npm audit --omit=dev не показва критични уязвимости.
Никоя тайна не е в променлива с NEXT_PUBLIC_ или във файл в Git.
Ключовете за WooCommerce имат само нужните права и могат да се сменят бързо.
Наблюдението следи витрината, API на WordPress и поръчките, а бекъпите се проверяват с възстановяване.

Кой следи всичко това всеки ден

Ако магазинът Ви е на класически WordPress и работи добре, не е нужно да преминавате към headless заради сигурността. Повечето защити от ръководството за защита на WordPress сайт важат и там.

Ако имате headless сайт или обмисляте такъв, най-важното е някой да следи и двете страни. При активна поддръжка всеки ден сверяваме плъгините, темата и WordPress с базите данни за известни уязвимости (CVE) и ги обновяваме навреме, след тест в staging. Как работи това, е описано при проверката за уязвимости. Ако правите нов магазин, при изработката на headless онлайн магазин админ панелът може да е скрит от интернет, а защитата не свършва с пускането.

Често задавани въпроси

По-сигурен ли е headless WordPress от класическия?

Отчасти. Посетителите виждат приложение на Next.js и не стигат до WordPress, затова админът и API могат да се ограничат, а плъгините за публичната част вече не трябват. WordPress и плъгините му обаче пак имат нужда от обновления, а към останалите рискове се добавят и тези на новата система, Next.js и пакетите от npm.

Как може да се скрие админът на WordPress при headless сайт?

Има три често срещани начина. Сървърът може да приема заявки към WordPress само от IP адресите на сървъра на Next.js и на офиса, всяка заявка към админа може да минава първо през услуга за достъп с фирмен вход, а редакторите могат да влизат през VPN. Ако браузърът на купувача говори директно с WooCommerce, например за количката, тези адреси остават публични, така че WordPress се затваря за всички останали, когато количката и поръчките минават през сървъра на Next.js.

Трябва ли да обновявам WordPress и плъгините при headless сайт?

Да. Според годишния доклад на Patchstack през 2025 г. в екосистемата на WordPress са открити 11 334 нови уязвимости, 91% от тях в плъгини. Скритият админ намалява риска, но данните от витрината, например поръчка с адрес за доставка, пак влизат в WooCommerce и минават през кода на плъгините, затова обновленията остават най-важната защита.

Какво показва REST API на WordPress на непознати?

По замисъл REST API показва публикуваното съдържание на всеки, който попита. Адресът /wp-json/wp/v2/users показва без вход потребителите, които са публикували съдържание, с името и slug, който обикновено издава потребителското име. Плъгините могат да добавят и свои адреси без проверка на правата, а те остават публични.

Мога ли просто да изключа REST API?

Не. WordPress използва REST API и в админа, а headless сайтът няма откъде другаде да взема съдържанието си. Ограничете кой може да стига до API, ако витрината може да го чете от сървъра, или затворете отделните адреси, които не трябват.

Какви бяха критичните уязвимости в Next.js през 2025 г.?

CVE-2025-29927 от 21 март 2025 г., с оценка 9.1 по CVSS, позволяваше проверките за достъп в middleware да се заобиколят с една специална заглавка в заявката. CVE-2025-55182 от 3 декември 2025 г., с максималната оценка 10, позволяваше изпълнение на чужд код без вход през React Server Components, а CISA я добави в каталога на използваните в атаки уязвимости два дни по-късно. И при двете решението беше обновяване.

Как да пазя тайните ключове между WordPress и Next.js?

Ключовете остават на сървъра, защото в Next.js променливите, които започват с NEXT_PUBLIC_, се вграждат в кода за браузъра и всеки може да ги прочете. Файловете .env не влизат в Git, а всеки ключ има само правата, които му трябват, например ключ на WooCommerce, който само чете продукти, не бива да може да пише. Смяната на ключ трябва да отнема минути и да не спира магазина.

Кои версии на Next.js получават поправки за сигурност?

Поправките за сигурност стигат само до текущата и предишната основна версия на Next.js, всяка до две години след излизането ѝ. Според политиката на Next.js версия 14 и по-старите вече не се поддържат и поправки за тях излизат само по изключение. Извън самия Next.js пускайте npm audit в папката на проекта или включете известията на Dependabot в GitHub, за да научавате за уязвими пакети.

Източници