Zatvaranje WordPress XML-RPC funkcije znači onemogućavanje udaljenih zahtjeva prema xmlrpc.php datoteci, čime se brzo smanjuju brute force pokušaji, pingback zloupotrebe i nepotreban bot promet. Ako ne koristite Jetpack, WordPress mobilnu aplikaciju, stare alate za udaljeno objavljivanje ili posebne integracije koje zahtijevaju XML-RPC, zatvaranje ovog servisa je siguran i efikasan korak za većinu WordPress stranica. Najbolje rezultate daje blokiranje pristupa xmlrpc.php na nivou servera – Apache, LiteSpeed, Nginx ili putem WAF pravila – jer time zahtjev ne dolazi ni do WordPressa, što je performansno bolje od zatvaranja putem plugina.
Ova vodič daje detaljno objašnjenje zašto i kada zatvoriti XML-RPC, kada ga ostaviti otvorenim, te kako to sigurno napraviti na različitim serverima. Bilo da ste na Hostragons infrastrukturi ili drugom hosting rješenju, cilj je smanjiti površinu napada bez rizika po funkcionalnost stranice, optimizirati potrošnju resursa i kreirati stabilan sigurnosni standard. Ako tražite brz i siguran temelj za WordPress hosting, WordPress hosting je ključan dio procesa.
Šta je XML-RPC i čemu služi na WordPressu?
XML-RPC je stari protokol za razmjenu podataka između sistema putem HTTP-a u XML formatu. Na WordPressu se ova funkcija realizuje kroz xmlrpc.php datoteku smještenu u root direktorijumu. Historijski gledano, XML-RPC je korišten za objavljivanje sa mobilne aplikacije, upravljanje komentarima na daljinu, pingback obavijesti i interakciju s trećim servisima.
Danas je WordPress REST API preuzeo glavnu ulogu, pa je XML-RPC postao manje bitan. Ipak, xmlrpc.php je i dalje dostupan na mnogim instalacijama i predstavlja jasan, automatiziran meta target za napadače. Botovi koji skeniraju IP opsege često u nekoliko minuta testiraju xmlrpc.php na novom domeni. Stoga je pri kupovini nove domene i prije objavljivanja stranice važno razmisliti o osnovnoj sigurnosti (Provjera domene).
Kada je XML-RPC zaista potreban?
Većina WordPress stranica ne treba XML-RPC. Jetpack još koristi neke stare funkcije, WordPress mobilna aplikacija zahtijeva XML-RPC za određene zadatke, kao i neki automatizirani servisi i desktop blog editori. Također, custom integracije mogu koristiti xmlrpc.php za slanje sadržaja ili podatke na daljinu. Zbog toga je preporučljivo provjeriti vaš workflow prije zatvaranja.
Jednostavna provjera: ako sadržaj unosite samo kroz wp-admin panel, ne koristite Jetpack, ne objavljujete preko mobilne aplikacije i developer nije postavio custom XML-RPC integraciju, vrlo vjerovatno vam ova funkcija nije potrebna. Većina poslovnih, blog, katalog i WooCommerce stranica radi bez XML-RPC-a. Ipak, ako imate kritične procese poput plaćanja i dostave, testirajte promjene izvan radnog vremena.
Zašto je WordPress XML-RPC meta za brute force napade?
Brute force je metod gdje napadač automatski pokušava razne kombinacije korisničkih imena i šifri. U WordPressu se najčešće napada wp-login.php, ali XML-RPC je još pogodniji jer omogućava više pokušaja u jednom HTTP requestu. Posebno system.multicall metoda olakšava masovne pokušaje s manjim brojem requestova, što otežava detekciju.
Na primjer, 500 pokušaja preko wp-login.php su 500 zasebnih requestova, dok XML-RPC može to spakovati u mnogo manje zahtjeva. Rezultat je veće opterećenje CPU-a, PHP worker-a, baze podataka, a pravi posjetitelji dobijaju sporije odgovore. U shared hosting okruženju ovo je i sigurnosni i performansni problem.
Još jedan rizik je pingback zloupotreba. Pingback je zamišljen kao obavijest da je neko linkao vaš sadržaj, ali se može koristiti za DDoS ili targetiranje trećih stranica. Zatvaranjem XML-RPC-a smanjujete i takvu zloupotrebu.
Brza usporedba metoda zatvaranja XML-RPC-a
| Metoda | Efikasnost | Performanse | Za koga je? | Šta paziti? |
|---|---|---|---|---|
| Server-side blokiranje | Vrlo visoka | Najbolje | Većina Apache, LiteSpeed, Nginx stranica | Pogrešna pravila mogu poremetiti konfiguraciju, obavezno backup |
| WAF ili firewall blokiranje | Visoka | Odlično | Cloudflare, server WAF ili hosting sigurnost | Pravilo mora blokirati samo xmlrpc.php |
| Plugin zatvaranje | Srednja | Srednje | Korisnici bez tehničkog iskustva | Zahtjev dolazi do WordPressa, resursi se i dalje troše |
| Kod filter | Srednja | Srednje | Developer teme ili custom plugin | Preporučljivo koristiti child theme ili custom plugin |
| Samo rate limit | Srednja | Dobro | Stranice koje djelimično trebaju XML-RPC | Nije potpuno zatvaranje, threshold mora biti dobro postavljen |
Kao što tabela pokazuje, najbrži i najjači način je zatvaranje na serveru ili WAF-u ako XML-RPC nije potreban. Plugin je lak za postaviti, ali napadi dolaze do PHP-a i troše resurse. Zato je za prometne, e-commerce ili napadnute stranice prioritet server-side blokiranje.
Prije početka: kontrolna lista
Osnovni princip sigurnosti je prvo mjeriti, imati plan povratka i backup. Zatvaranje XML-RPC-a je uglavnom bezopasno, ali nikad ne mijenjajte produkciju naslijepo. Ova lista vam pomaže da izbjegnete greške:
- Imate backup datoteka i baze star maksimalno 24 sata. Backup je obavezno prije svih sigurnosnih ili plugin promjena.
- Provjerite koristite li Jetpack, mobilnu aplikaciju, alat za udaljeno objavljivanje ili posebne integracije.
- Pregledajte server logove za xmlrpc.php zahtjeve. Ako imate desetine ili stotine requestova u minuti, moguće je da ste meta napada.
- Promjenu radite izvan najprometnijeg vremena. Na WooCommerce shopu testirajte checkout, login, registraciju nakon promjene.
- Imate način za povratak promjena – komentiranje ili brisanje pravila preko file managera, FTP-a ili SSH-a.
Profesionalni hosting sa redovnim backupom, najnovijim PHP-om, izolacijom korisničkih računa i firewall podrškom drastično poboljšava sigurnost. Za više informacija o infrastrukturi pogledajte Siguran Web Hosting i za opštu sigurnost SSL certifikat.
Metoda 1: Zatvaranje XML-RPC-a na Apache/LiteSpeed (.htaccess)
Najčešće se koristi .htaccess u root direktoriju za blokiranje xmlrpc.php na Apache i LiteSpeed serverima. LiteSpeed podržava Apache .htaccess, pa je ova metoda primjenjiva na većini hostinga. Prednost je što se zahtjev odbija prije nego što WordPress pokrene bilo šta.
Korak po korak
- Otvorite file manager iz hosting panela ili se spojite FTP-om na public_html.
- Pronađite .htaccess i napravite backup. Ako ga ne vidite, uključite prikaz skrivenih datoteka.
- Bez brisanja WordPress pravila, dodajte XML-RPC blok na vrh datoteke.
- Pravilo treba odbiti svaki zahtjev prema xmlrpc.php.
- Sačuvajte i testirajte otvaranjem domena.com/xmlrpc.php u browseru.
Na Apache 2.4 i LiteSpeed koristi se Require all denied. Na starijem Apache 2.2 Deny from all, ali preporučuje se prelazak na novije servere radi sigurnosti. Ako još koristite stari Apache, to je signal za opšti upgrade.
Ispravno blokiranje daje 403 Forbidden, 404 Not Found ili sličnu poruku. Ako vidite "XML-RPC server accepts POST requests", xmlrpc.php je i dalje dostupan i pravilo ne radi.
Metoda 2: Zatvaranje XML-RPC-a na Nginx serveru
Nginx ne koristi .htaccess, pa se pravilo mora dodati u server block konfiguraciju. Ako imate managed hosting, možda nemate pristup; u tom slučaju tražite od podrške da blokiraju xmlrpc.php.
Osnovno je dodati location = /xmlrpc.php blok koji odbija zahtjev (403) ili prikazuje 404. 404 je diskretnije rješenje, manje informacija botovima. Nakon dodavanja pravila, testirajte konfiguraciju i reloadajte Nginx. Jedan znak greške može srušiti cijelu stranicu, pa budite pažljivi.
Na VPS ili dedicated serveru pratite logove nakon promjene. Ako xmlrpc.php zahtjevi sada završavaju sa 403 ili 404, pravilo radi. Ako napadi traju, dodajte fail2ban, rate limit ili WAF. Za detaljnije vodiče pogledajte Sigurnost VPS servera.
Metoda 3: Zatvaranje XML-RPC-a pluginom
Za korisnike koji ne žele raditi s datotekama, sigurnosni pluginovi su praktično rješenje. Wordfence, Solid Security, All-In-One Security i slični nude opciju zatvaranja XML-RPC-a, pingbacka ili blokiranja prijava preko XML-RPC-a. Ovo je brza startna točka za male blogove i poslovne stranice.
Međutim, plugin blokira tek nakon što WordPress pokrene PHP proces, pa napadač i dalje može trošiti resurse. Zato plugin rješenje nije idealno za napadnute stranice – kombinujte ga s server-side ili WAF blokiranjem.
Šta paziti kod plugin rješenja
- Plugin preuzimajte samo iz zvaničnog WordPress repozitorija ili provjerenih izvora.
- Izbjegavajte pluginove bez updatea. Aktivno održavanje je bitan sigurnosni signal za 2026.
- Ne koristite više pluginova za istu funkciju – konflikti mogu izazvati greške u loginu, cacheu ili datotekama.
- Nakon promjene testirajte site health, forme, login i checkout.
- Redovno pregledajte plugin logove. Ako napadi traju, blokirajte napadačke IP adrese ili dodajte WAF pravilo.
Metoda 4: WAF, CDN i firewall blokiranje

Web Application Firewall (WAF) je među najjačim slojevima zaštite. Cloudflare i slični CDN-ovi mogu blokirati xmlrpc.php zahtjeve prije nego dođu do servera. ModSecurity ili custom WAF pravila na hostingu rade isto. Ovaj sloj je idealan za filtriranje masovnog bot prometa.
WAF pravilo mora jasno blokirati zahtjeve prema xmlrpc.php. Ako vam XML-RPC treba djelimično, dozvolite pristup samo određenim IP adresama (npr. automatizirani servis). Ostatak blokirajte. Ova metoda balansira sigurnost i poslovne potrebe.
WAF je efikasniji uz SSL. Na stranicama bez HTTPS-a login i session su dodatno izloženi. Uz zatvaranje XML-RPC-a, preporučuje se kompletan site na HTTPS-u, HSTS headers i redovno praćenje SSL certifikata. Za više informacija pogledajte SSL certifikat i Besplatna instalacija SSL-a.
Kako testirati zatvaranje XML-RPC-a
Nije dovoljno samo provjeriti da se stranica otvara. Provjerite:
- Otvorite domena.com/xmlrpc.php u browseru. Trebali biste dobiti 403, 404 ili praznu stranicu. Poruka "XML-RPC server accepts POST requests" ne smije biti vidljiva.
- Logirajte se u WordPress admin panel sa standardnim podacima. Login mora raditi nezavisno od XML-RPC-a.
- Testirajte kontakt forme, komentare, registraciju, WooCommerce checkout.
- Pregledajte server logove za xmlrpc.php zahtjeve. Ako su 403 ili 404, pravilo radi.
- Pregledajte logove sigurnosnog plugina. Trebali biste vidjeti pad u broju bot pokušaja.
Napredni test je slanje POST zahtjeva iz terminala, ali za većinu korisnika browser i logovi su dovoljni. Ako Jetpack, mobilna aplikacija ili integracija ne radi nakon promjene, XML-RPC vam stvarno treba – razmislite o IP whitelist ili rate limit rješenju.
Je li zatvaranje XML-RPC-a dovoljno? Dodatne mjere
Zatvaranje XML-RPC-a je brz i efikasan korak protiv brute force napada, ali nije potpuna zaštita. Napadi se mogu nastaviti na wp-login.php, REST API, stare pluginove ili putem provaljenih šifri. Zato je WordPress sigurnost slojevita.
Osnovne mjere koje morate provesti
- Koristite snažne šifre i jedinstvena korisnička imena. "admin" je i dalje najlakši meta target.
- Dodajte dvofaktorsku autentifikaciju (2FA) na admin račune – drastično smanjuje rizik od provaljenih šifri.
- Ograničite broj login pokušaja – rate limit ili plugin za sigurnost.
- Redovno ažurirajte WordPress, pluginove i teme. Stari pluginovi su česti izvor proboja.
- Obrišite nepotrebne pluginove i teme – pasivni, ali stari pluginovi su sigurnosna rupa.
- Provjerite file permissione – nepotrebna write prava povećavaju rizik od malicious upload-a.
- Redovno radite backup i testirajte restore. Backup bez testa je pretpostavka.
- Koristite provjereni hosting – izolacija, najnoviji PHP, WAF i backup smanjuju efekte napada.
Primjer: Ako zatvorite XML-RPC, ali admin lozinka ostane 123456, napad je i dalje moguć. Snažna šifra, 2FA, update, WAF i siguran hosting zajedno zaustavljaju većinu bot napada. To je važno i za SEO – nesigurne stranice gube vidljivost zbog spam redirecta, index pollutiona i lošeg user experiencea.
Performanse i SEO: Utjecaj zatvaranja XML-RPC-a
XML-RPC napadi nisu direktan SEO faktor, ali produženo vrijeme odgovora, loši Core Web Vitals i pad user experiencea mogu utjecati na rangiranje. Ako botovi troše server, stranica se usporava, raste broj 500 grešaka i timeout-a, Googlebot postaje oprezniji.
Primjer: Homepage se inače učitava u 300 ms, ali sa 1000 requesta na xmlrpc.php po minuti, server kasni 2+ sekunde. Korisnici čekaju, konverzija pada, Search Console pokazuje oscilacije. Zatvaranjem XML-RPC-a na nivou servera, nepotreban load se presijeca prije WordPressa.
SEO zahtijeva sigurnu i brzu stranicu, što podrazumijeva HTTPS, najnoviji PHP, brze diskove, cache, čist theme i smanjenje površine napada. WordPress sigurnosne postavke su tema i za SEO i za content timove. Na Hostragons blogu ovo je povezano s Optimizacija brzine WordPress-a i Lista provere tehničkog SEO-a.
Alternativne strategije ako ne možete potpuno zatvoriti XML-RPC
Ponekad nije moguće potpuno blokirati XML-RPC – mobilno objavljivanje, poslovna automatizacija ili legacy integracije zavise od njega. Cilj je tada ograničiti pristup:
Prvo, IP whitelist – dozvolite samo poznatim servisima pristup xmlrpc.php, ostale blokirajte.
Drugo, rate limit – spriječite previše requestova sa istog IP-a u kratkom periodu. Nije potpuno zatvaranje, ali smanjuje napade.
Treće, isključite pingback metode i dozvolite samo potrebne. Ovo traži developer pristup.
Četvrto, dodajte sigurnosni sloj – HTTP basic auth, VPN, IP restriction ili WAF challenge. Time smanjujete rizik od javnog endpointa. Dugoročno, najbolje je migrirati legacy integracije na REST API.
Praktični roadmap za Hostragons korisnike
Ako hostujete WordPress na Hostragonsu, prvo analizirajte potrebe, zatim odaberite najmanje kompleksnu metodu. Na shared ili WordPress hosting paketima .htaccess izmjena je često dovoljna. Na VPS ili dedicated serverima, kombinujte Nginx, Apache, LiteSpeed i WAF.
Redoslijed: Prvo backup, zatim provjera integracija koje koriste XML-RPC, onda zatvaranje na serveru, testiranje i monitoring logova 24 sata. Ako napadi traju, dodajte WAF, IP blokiranje i limit login pokušaja. Na kraju, provedite 2FA, update politiku, backup i SSL.
Ovo je osnovni sigurnosni korak, a ne prodajni upgrade. Ako imate stalne probleme zbog starog PHP-a, slabog servera ili lošeg firewalla, razmislite o novom hostingu. WordPress optimizirani hosting sa sigurnosnim slojevima daje otpornost i bolji performance. Za više informacija pogledajte WordPress hosting, cloud server i SSL certifikat.
Često postavljena pitanja
Može li zatvaranje WordPress XML-RPC-a pokvariti moju stranicu?
Većina standardnih WordPress stranica neće imati problema nakon zatvaranja XML-RPC-a. Admin panel, teme, sadržaj, forme i posjetitelji rade normalno. Jetpack, mobilna aplikacija i posebne integracije mogu imati problem – provjerite potrebe i testirajte funkcionalnosti nakon promjene.
Kako provjeriti je li XML-RPC zatvoren?
Otvorite domena.com/xmlrpc.php u browseru. Ako vidite "XML-RPC server accepts POST requests", datoteka je dostupna. Ako je 403, 404 ili access denied, pravilo radi. Za preciznu provjeru analizirajte logove servera za status kodove na xmlrpc.php.
Hoće li zatvaranje XML-RPC-a zaustaviti sve brute force napade?
Većinu napada preko XML-RPC-a hoće, ali brute force može i dalje ići preko wp-login.php. Zato kombinujte zatvaranje XML-RPC-a sa snažnim šiframa, 2FA, limitom login pokušaja, WAF-om i ažuriranim pluginovima.
Šta ako koristim Jetpack?
Neke Jetpack funkcije traže otvoren XML-RPC. Provjerite koje module koristite prije zatvaranja. Alternativno, dozvolite pristup samo Jetpack IP adresama ili definirajte WAF pravila za selektivni pristup.
Plugin ili server-side zatvaranje – šta je bolje?
Najveći sigurnost i performanse daje server-side ili WAF blokiranje – odbija zahtjev prije WordPressa. Plugin je lak za korisnike bez iskustva, ali ne zaustavlja napade na resurse. Ako možete, koristite server pravilo; ako ne, kombinujte pouzdan plugin i WAF.
Kratko i jasno: zaključak i sljedeći korak
Zatvaranje WordPress XML-RPC-a je brz i efikasan način da smanjite brute force, pingback zloupotrebe i bot promet na stranicama koje ne trebaju ovu funkciju. Najsigurnije je blokirati xmlrpc.php na serveru ili WAF-u, zatim dodati login sigurnost, 2FA, ažuriranja, SSL i backup za slojevitu zaštitu. Ako želite analizirati infrastrukturu, pogledajte Hostragons WordPress hosting i sigurnosna rješenja, a za početak provjerite kontrolnu listu iz ovog vodiča.