Puține magazine lucrează singure. Programul de facturare, gestiunea depozitului, un monitor de prețuri sau o conexiune către un marketplace au nevoie de un drum prin care ajung la comenzi și la produse. În PrestaShop acest drum este webservice-ul, iar el se deschide cu o cheie.
Cheia nu funcționează cu parolă: cheia însăși este actul de intrare. Cine o are poate face cu datele magazinului exact atât cât îi permit drepturile cheii. De aceea merită parcursă din când în când lista: câte chei sunt active, a cui este fiecare, la ce ajunge și dacă o mai folosește cineva.
Nu mă pricep la partea tehnicăPe scurt: despre ce este verificarea cheilor
La magazin se conectează și programe din afară: facturarea, programul de contabilitate, depozitul, uneori un instrument făcut de un dezvoltator anterior. Fiecare primește o cheie cu care ajunge la date.
Aceste chei nu expiră de la sine. După încheierea unui contract, după terminarea unui proiect sau după schimbarea unui program, cheia rămâne de obicei pe loc și funcționează ca în prima zi.
De făcut: cereți lista cheilor și parcurgeți la ce servește fiecare. Ce nu poate fi identificat sau nu mai este folosit poate fi dezactivat. Textul de mai jos poate fi trimis celui care întreține magazinul.
Întrebări pentru cel care întreține magazinul
Câte chei de webservice sunt active pe magazin și cărui program îi aparține fiecare? La ce ajunge fiecare: comenzi, clienți, produse, doar citire sau și scriere? Dacă există mai multe magazine, pe ce magazine este valabilă fiecare cheie? Există vreuna nefolosită, care poate fi dezactivată? Pe ramura 9, magazinul folosește clienți Admin API și, dacă da, cui au fost emiși?
Ce este o cheie de webservice și ce deschide?
PrestaShop pune la dispoziția programelor externe o interfață proprie, servită sub adresa magazinului, pe calea /api/. Prin ea pot fi citite și modificate comenzile, clienții, produsele, stocul și încă o serie de date.
Interfața este oprită implicit și se pornește din back office, la Parametri avansați > Webservice. Fiecare program care se conectează primește o cheie proprie, un text de 32 de caractere. Documentația spune limpede un lucru: nu există parolă, cheia singură este actul de intrare. Tocmai de aceea ghidul PrestaShop insistă asupra drepturilor acordate unei chei și asupra persoanelor cărora le este dezvăluită.
Drepturile nu se dau în bloc: se stabilesc pe fiecare resursă și pe fiecare operațiune. O cheie poate citi produsele și scrie comenzile, fără să aibă deloc acces la datele clienților. Recomandarea documentației este fără echivoc: nicio cheie nu ar trebui să primească toate drepturile pe toate resursele.
Drepturile unei chei existente pot fi verificate oricând: apelând adresa /api/ a magazinului cu acea cheie, răspunsul enumeră resursele la care ajunge și operațiunile permise.
De ce merită verificate cheile acum?
În versiunea de securitate PrestaShop din 9 noiembrie 2026, două remedieri privesc chiar webservice-ul, iar ambele se referă la instalările care servesc mai multe magazine. Una (CVE-2026-71519) împiedică o cheie să ajungă la datele unui client din afara magazinului ei, pentru că verificarea magazinului lipsea la nivel de înregistrare. Cealaltă (CVE-2026-71531) împiedică o cerere cu parametrul id_shop=all să iasă din setul de magazine pentru care a fost emisă cheia.
Remedierile ajung odată cu actualizarea. Punerea în ordine a cheilor este însă o muncă separată: actualizarea nu dezactivează o cheie pe care nimeni nu a folosit-o de un an și nu restrânge drepturile unei integrări vechi.
Ce aduce Admin API pe ramura 9?
Pe ramura 9, pe lângă webservice-ul clasic, există Admin API, pornit implicit. Aici actul de intrare nu mai este o singură cheie: programul care se conectează cere un token prin OAuth2, iar drepturile sunt descrise de domenii de acces (scope). În regim de producție, totul merge doar pe HTTPS.
În practică, asta adaugă două întrebări pe listă. Prima: câți clienți API sunt înregistrați și cui îi aparține fiecare; magazinul răspunde la asta pe punctul final /admin-api/api-client/infos, cu numele clientului și cu starea lui. A doua: cât de restrânse sunt domeniile de acces date unui client.
Aceeași versiune din noiembrie remediază două probleme ale Admin API: accesul unui client dezactivat nu înceta, iar un client cu drept de scriere își putea acorda singur domenii suplimentare. Cine folosește un client API pe ramura 9 ar trebui să parcurgă lista clienților după actualizare.
Cum arată o evidență a cheilor pusă la punct?
Nu e nevoie de un sistem separat, un tabel este de ajuns. Fiecare cheie activă ar trebui să poarte patru informații:
- Cui îi aparține. Pentru asta există câmpul de descriere; acolo intră numele programului și al partenerului, nu cuvântul „test”.
- La ce ajunge. Pe resurse și pe operațiuni: citire, scriere, ștergere.
- Pe ce magazin. Cu mai multe magazine, cheia are o asociere de magazin; câmpul apare doar în regim multistore, iar lăsat gol dă un acces greu de explicat mai târziu.
- Dacă o mai folosește cineva. Dacă programul din spatele cheii nu mai există, starea cheii poate fi trecută pe dezactivat. Dezactivarea este reversibilă, ștergerea nu.
Momentele firești ale unei verificări sunt încheierea unui contract cu un dezvoltator sau o agenție, schimbarea unui program și o versiune de securitate precum cea de acum.
Ce este de făcut pe lângă actualizare
Dacă pe magazin nu rulează versiunea din 9 noiembrie 2026, acesta este primul pas. Dacă actualizarea nu se poate face acum, remedierile pot fi mutate în versiunea care rulează: fișierele afectate sunt înlocuite cu cele reparate, iar restul magazinului rămâne neatins. Asta face modulul Remedieri de securitate PrestaShop, cu o copie de siguranță în prealabil, astfel încât fiecare remediere să poată fi anulată. Ce probleme privesc un anumit magazin arată modulul Scanare de securitate PrestaShop.
Ce este de făcut acum?
- Cereți lista cheilor de la cel care întreține magazinul, împreună cu câmpul de descriere.
- Numiți fiecare cheie. Cea în spatele căreia nu stă niciun program sau partener este suspectă.
- Restrângeți drepturile la ce folosește efectiv programul. Scrierea și ștergerea sunt necesare mai rar decât sunt bifate.
- Cu mai multe magazine, parcurgeți asocierea de magazin cheie cu cheie.
- Dezactivați cheile nefolosite în loc să le ștergeți imediat și urmăriți dacă semnalează ceva vreun partener.
- Actualizați la 9.2.1 sau 8.2.9, ca să intre și cele două remedieri ale webservice-ului.
Întrebări frecvente
[faq]
Q: Unde văd câte chei sunt active pe magazin?
A: În back office, la Parametri avansați > Webservice. Fiecare rând este o cheie, cu starea și descrierea ei.
Q: Expiră cheile de la sine?
A: Nu. O cheie clasică de webservice trăiește până este dezactivată sau ștearsă. Pe ramura 9, tokenul Admin API are o durată de viață, dar clientul rămâne și acolo până este dezactivat.
Q: Este suficientă dezactivarea sau cheia trebuie ștearsă?
A: Dezactivarea oprește accesul imediat și poate fi anulată, așa că este primul pas la o verificare. Ștergerea are sens când este sigur că acea cheie nu mai este necesară.
Q: De unde știu dacă o cheie mai este folosită?
A: Jurnalul serverului web arată cererile care încep cu /api/. Dacă în spatele unei chei nu a mai fost nicio cerere de luni de zile, dezactivarea are un risc mic.
Q: Trebuie oprit webservice-ul dacă nu îl folosim?
A: Dacă niciun program nu se conectează, comutatorul poate fi oprit, iar calea /api/ nu mai răspunde. Dacă este nevoie mai târziu, se pornește din același loc.
Surse: Documentația webservice PrestaShop, Documentația Admin API, Comunicatele de securitate PrestaShop
