Gids voor het beveiligen van API-aanroepen in een WordPress-omgeving

Inleiding: twee richtingen, twee verschillende problemen

Er wordt over "API-beveiliging" gesproken alsof het één onderwerp is. Het zijn er twee, en ze verwarren is de oorzaak van de meeste fouten:

INKOMEND : wat de wereld aan uw WordPress kan vragen  → REST-API, webhooks
UITGAAND : wat uw WordPress aan de wereld vraagt      → sleutels, leveranciers, AI

Het inkomende is een rechtenprobleem: wie wat mag vragen. Het uitgaande is een geheimenprobleem: waar de sleutel staat en wie hem kan lezen. Dit artikel behandelt beide, te beginnen met het meest verwaarloosde.

1. Uitgaand — waar de sleutel staat

Dit is het punt dat al het andere tenietdoet als u het misloopt.

Nooit in een versiebeheerd bestand. Een sleutel in een repository blijft in de geschiedenis staan, ook als u hem daarna wist. Intrekken is de enige echte oplossing: het bestand wijzigen volstaat niet.

Nooit in de code van een thema. Een thema wordt gekopieerd, gedeeld, naar een testomgeving uitgerold, naar een dienstverlener gestuurd.

Nooit in JavaScript aan de clientkant. Een sleutel die in de browser aankomt, is een openbare sleutel. Deze fout komt vaker voor dan het lijkt, juist omdat hij prima "werkt".

In een omgevingsvariabele van de server, of in de geheimenkluis van uw hosting. En met een organisatorische regel die net zoveel waard is als de technische: één sleutel per klant en per gebruik. Een gedeelde sleutel maakt elke toerekening onmogelijk, en een overschrijding wordt anoniem.

Dat laatste punt maakt ook het budget leesbaar — de volledige redenering staat in het budget van uw bureau optimaliseren met een persoonlijke API-sleutel.

2. Uitgaand — wat u bij elke aanroep moet controleren

• Een expliciete time-out. Zonder blokkeert een trage leverancier uw pagina. Het is de meest voorkomende oorzaak van "de site lag eruit" terwijl hij in werkelijkheid op een antwoord wachtte.
• Een uitgavenplafond bij de leverancier, per sleutel. Het is een structurele garantie: die houdt stand, zelfs als een automatische verwerking in een lus schiet. Geen enkele contractuele afspraak biedt dat, want die werkt achteraf.
• Een frequentielimiet aan uw kant, zodat een slecht gesloten lus u een incident kost en niet een maandbudget.
• Geen overbodige gegevens verzonden. Het best beschermd is wat nooit is vertrokken: heeft de verwerking alleen de producttekst nodig, dan heeft ze de klantnaam niet nodig. Dat is het principe uit waarom gegevensbescherming uw beste bondgenoot is.
• Geen geheimen in de logboeken. Een foutmelding die het volledige verzoek uitschrijft, zet uw sleutel in een bestand dat bewaard wordt en soms naar een derde gaat.

3. Inkomend — de REST-API en wat die standaard blootgeeft

WordPress stelt een standaard actieve REST-API beschikbaar. Dat is geen gebrek, maar drie dingen zijn goed om te weten:

1. Sommige routes zijn bewust openbaar, en enkele geven de auteurslijst van de site prijs — dus accountnamen die bruikbaar zijn voor een wachtwoordaanval. Die route beperken kost een paar regels.
2. Elke plugin kan eigen routes toevoegen. Uw inkomende oppervlak groeit bij elke installatie, zonder dat iemand ernaar kijkt. Nog een argument om uw plugins door te lichten.
3. Een eigen route zonder controle op capaciteiten staat voor iedereen open. Dat is de klassieke fout bij maatwerk: u controleert de nonce en vergeet de capaciteit. De nonce bewijst waar het verzoek vandaan komt, niet het recht om het uit te voeren. U hebt beide nodig.

4. Inkomend — de webhooks

Een webhook is een openbare URL die code uitvoert. Drie regels, en geen ervan is optioneel:

• controleer de handtekening die de verzender meestuurt, stelselmatig. Zonder controle kan iedereen die de URL kent de verwerking starten;
• maak de verwerking idempotent: hetzelfde event dat twee keer binnenkomt, mag geen twee effecten hebben. Leveranciers sturen opnieuw, dat is normaal;
• antwoord snel en werk daarna. Een webhook die een lange verwerking uitvoert vóór hij antwoordt, veroorzaakt hernieuwde verzendingen, en die veroorzaken dubbelingen.

5. De vijf fouten die u overal tegenkomt

1. De sleutel aan de clientkant — het werkt, en het is openbaar.
2. De nonce zonder de capaciteit — u controleert de herkomst, niet het recht.
3. De sleutel gedeeld tussen klanten — toerekening onmogelijk, intrekken onmogelijk zonder iedereen te raken.
4. Geen time-out — de storing van de leverancier wordt de uwe.
5. Het geheim in de logboeken — één keer geschreven, maandenlang bewaard.

6. Het protocol, op één pagina

• Geen enkele sleutel in een versiebeheerde repository, in een thema of in client-JavaScript
• Eén sleutel per klant en per gebruik, in een omgevingsvariabele of een geheimenkluis
• Uitgavenplafond ingesteld bij de leverancier, per sleutel, met een tussentijdse melding
• Expliciete time-out bij elke uitgaande aanroep
• Frequentielimiet op automatische verwerkingen
• Eigen REST-routes: nonce én controle op capaciteiten, zonder uitzondering
• Webhooks: handtekening gecontroleerd, verwerking idempotent, snel antwoord
• Logboeken nagelezen: geen geheimen, geen volledige verzoeken uitgeschreven
• Intrekkingsprocedure op schrift — en één keer beproefd, niet aangenomen

Dat laatste punt is wat niemand doet en het enige dat telt op de dag dat het nodig is.

Conclusie

De beveiliging van API-aanroepen rust niet op een hulpmiddel maar op twee vragen die u altijd moet kunnen beantwoorden: waar staan mijn sleutels, en wie kan ze lezen? en wat kan de wereld van mij vragen zonder zich te identificeren?

De meeste incidenten komen niet voort uit een geraffineerde aanval, maar uit een sleutel die stond waar hij niet hoorde en een route die niet controleerde wat ze dacht te controleren.

De proef: als u vanavond al uw sleutels moest intrekken, zou u dan weten waar ze staan en hoe lang het zou duren? Kunt u dat niet beantwoorden, dan is dat het werk dat als eerste moet gebeuren.

Verder lezen: geavanceerde WordPress-hardening, proactieve bescherming tegen zerodaydreigingen en de AVG+-aanpak en de architectuur met persoonlijke API-sleutel. Onze premium-extensies zijn beschikbaar met volledige terugbetaling binnen 14 dagen: bekijk de catalogus.