Data-sanering en -validatie met WordPress

Goede beveiliging is van cruciaal belang om uw site of die van uw thema- of plug-in-gebruikers veilig te houden. Onderdeel hiervan is een juiste gegevensvalidatie en -zuivering. In dit artikel gaan we kijken waarom dit belangrijk is, wat er moet gebeuren en welke functies WordPress biedt om te helpen.

Aangezien er verschillende interpretaties lijken te zijn van wat de termen 'validatie', 'ontsnappen' en 'ontsmetting' betekenen, zal ik eerst verduidelijken wat ik hiermee bedoel in dit artikel:

bevestiging - Dit zijn de controles die worden uitgevoerd om ervoor te zorgen dat de gegevens u hebben is wat het is moeten worden. Bijvoorbeeld dat een e-mail eruit ziet als een e-mailadres, dat een datum een datum is en dat een getal een geheel getal is (of is gegoten als)
Ontsmetting / Ontsnappen - Dit zijn de filters die worden toegepast op gegevens om deze 'veilig' te maken in een specifieke context. Als u bijvoorbeeld HTML-code in een tekstgebied wilt weergeven, moet u alle HTML-tags vervangen door hun entiteitsequivalenten

Waarom is ontsmetting belangrijk?

Wanneer gegevens in een bepaalde context worden opgenomen (bijvoorbeeld in een HTML-document), kunnen die gegevens verkeerd worden geïnterpreteerd als een code voor die omgeving (bijvoorbeeld HTML-code). Als die gegevens schadelijke code bevatten, betekent het gebruik van die gegevens zonder deze te ontsmetten, dat die code wordt uitgevoerd. De code hoeft zelfs niet per se kwaadaardig te zijn om ongewenste effecten te veroorzaken. Het is de taak van sanering om ervoor te zorgen dat elke code in de gegevens niet als code wordt geïnterpreteerd - anders kun je eindigen als de school van Bobby Tables ...

'Exploits of a Mom' - xkcd

Een schijnbaar onschadelijk voorbeeld kan een zoekveld vooraf invullen met de term die op dit moment wordt bevraagd, met behulp van de niet-escapecode $ _GET [ 's']:

Dit opent een kwetsbaarheid waardoor javascript kan worden geïnjecteerd, bijvoorbeeld door iemand lastig te vallen om te bezoeken http://yoursite.com?s= "/>. De zoekterm 'springt' uit het waardeattribuut en het volgende deel van de gegevens wordt geïnterpreteerd als code en uitgevoerd. Om dit te voorkomen, biedt WordPress get_search_query die de gesanitiseerde zoekopdracht retourneert. Hoewel dit een 'onschuldig' exemplaar is, kan het geïnjecteerde script veel kwaadaardiger zijn en in het beste geval zou het het formulier 'breken' als zoektermen dubbele aanhalingstekens bevatten..

Hoe deze kwaadwillende (of anderszins) code mogelijk op uw site is terechtgekomen, is hier niet de zorg, maar veeleer om te voorkomen dat deze wordt uitgevoerd. We doen ook geen aannames over de aard van deze ongewenste code of de intentie ervan - het zou simpelweg een fout van de kant van de gebruiker kunnen zijn. Dit brengt mij bij regel nr.1 ...

Regel nr. 1: vertrouw op niemand

Het is een algemene stelregel die wordt gebruikt met betrekking tot data-sanering, en het is een goede. Het idee is dat u niet moet aannemen dat gegevens die door de gebruiker worden ingevoerd veilig zijn. Ook mag u niet aannemen dat de gegevens die u uit de database hebt gehaald veilig zijn - zelfs als u het 'veilig' had gemaakt voordat u het daar invoerde. In feite, of gegevens als 'veilig' kunnen worden beschouwd, heeft geen zin zonder context. Soms kunnen dezelfde gegevens in meerdere contexten op dezelfde pagina worden gebruikt. Titels kunnen bijvoorbeeld veilig offertes of dubbele aanhalingstekens bevatten wanneer inside-header-tags worden gebruikt, maar zullen problemen veroorzaken als ze worden gebruikt (zonder escapecodes) in een titelkenmerk van een linktag. Het is dus tamelijk zinloos om gegevens 'veilig' te maken bij het toevoegen ervan aan de database, omdat het vaak onmogelijk is om gegevens veilig te maken voor alle contexten tegelijkertijd. (Natuurlijk moet het veilig worden gemaakt om aan de database toe te voegen - maar daar komen we later op terug).

Zelfs als u alleen van plan bent om die gegevens in een specifieke context te gebruiken, bijvoorbeeld een formulier, is het nog steeds zinloos om de gegevens te schonen wanneer u naar de database schrijft, omdat u volgens regel nr. 1 kunt vertrouwen dat het nog steeds veilig is als u haal hem er weer uit.

Regel 2: Valideer op Input, Escape on Output

Dit is de procedurele stelregel die aangeeft wanneer u gegevens moet valideren en wanneer u deze schoonmaakt. Simpel gezegd - valideer uw gegevens (controleer het is wat het zou moeten zijn - en dat het 'geldig' is) zodra u het van de gebruiker ontvangt. Wanneer u deze gegevens gaat gebruiken, bijvoorbeeld wanneer u deze uitvoert, moet u deze ontsnappen (of zuiveren). Welke vorm deze sanering vereist, hangt geheel af van de context waarin je het gebruikt.

Het beste advies is om dit 'laat' te doen: ontsnappen aan uw gegevens onmiddellijk voordat u deze gebruikt of weergeeft. Op deze manier kunt u erop vertrouwen dat uw gegevens naar behoren zijn opgeschoond en hoeft u niet te onthouden of de gegevens eerder zijn gecontroleerd.

Regel nr. 3: vertrouw op WordPress

U denkt misschien: "OK, valideer voordat u naar de database schrijft en ontsmet wanneer u het gebruikt, maar moet ik er niet voor zorgen dat de gegevens veilig zijn om naar de database te schrijven?". In het algemeen, Ja. Wanneer u gegevens aan een database toevoegt, of eenvoudigweg een invoer gebruikt om met een database te werken, moet u aan de gegevens ontsnappen als er SQL-opdrachten in voorkomen. Maar dit brengt mij bij regel nr. 3, een regel die lijnrecht tegenover regel nr. 1 staat: vertrouw op WordPress.

In een vorig artikel nam ik de gebruikersinvoer (verzonden via een zoekformulier via AJAX) en gebruikte het direct met get_posts () om berichten terug te sturen die overeenkomen met die zoekopdracht:

 $ posts = get_posts (array ('s' => $ _ REQUEST ['term']));

Een oplettende lezer merkte dat ik geen sanering had uitgevoerd - en ze hadden gelijk. Maar dat hoefde ik niet. Wanneer u functies op hoog niveau gebruikt, zoals get_posts (), u hoeft zich geen zorgen te maken over het ontsmetten van de gegevens - omdat de databasequery's allemaal op de juiste manier zijn ontsnapt door de internets van WordPress. Het is geheel anders als u een directe SQL-query gebruikt, maar we zullen dit in een later gedeelte bekijken. Evenzo functies zoals de titel(), the_permalink (), de inhoud() enz. voeren hun eigen sanering uit (voor de juiste context).

Gegevensvalidatie

Wanneer u gegevens ontvangt die door een gebruiker zijn ingevoerd, is het belangrijk om dit te doen bevestigen het. (Met de instellingen-API, die in deze reeks wordt behandeld, kunt u een callback-functie opgeven om precies dit te doen). Ongeldige gegevens worden automatisch gecorrigeerd of het proces wordt afgebroken en de gebruiker wordt teruggestuurd naar het formulier om het opnieuw te proberen (hopelijk met een geschikte foutmelding). Het gaat hier niet om veiligheid, maar om validiteit - als u het goed doet, zorgt WordPress ervoor dat de gegevens veilig aan de database worden toegevoegd. Wat 'geldig' betekent, is aan jou - het kan een geldig e-mailadres betekenen, een positief geheel getal, een tekst met een beperkte lengte of een van een reeks gespecificeerde opties. Hoe je ook probeert om de geldigheid te bepalen, WordPress biedt veel functies die kunnen helpen.

Numbers

Bij het verwachten van numerieke gegevens is het bijvoorbeeld mogelijk om te controleren of de gegevens 'een of andere vorm van nummer' zijn is_int of is_float. Gewoonlijk volstaat het om de gegevens gewoon als numeriek te casten met: intval of floatval.

Als u ervoor wilt zorgen dat het nummer is gevuld met voorloopnullen, biedt WordPress de functie zeroise (). Welke de volgende parameters heeft:

Aantal - het nummer naar pad
Drempel - het aantal cijfers waarnaar het nummer wordt opgevuld

Bijvoorbeeld:

 echo zeroise (70,4); // Drukt 0070 af

E-mails

Om de geldigheid van e-mails te controleren, heeft WordPress de is_email () functie. Deze functie gebruikt eenvoudige controles om het adres te valideren. Het controleert bijvoorbeeld of het '@'-symbool bevat, dat het langer is dan 3 tekens, het domein alleen alfanumerieke tekens en koppeltekens bevat, enzovoort. Het is duidelijk dat het niet controleert of het e-mailadres daadwerkelijk bestaat. Ervan uitgaande dat het e-mailadres de cheques heeft doorgegeven, wordt het geretourneerd, anders wordt 'onwaar' geretourneerd.

 $ email = is_email ('someone@e^ample.com '); // $ email is ingesteld op false. $ email = is_email ('[email protected] '); // $ e-mail is ingesteld op '[email protected]'.

HTML

Vaak wilt u het alleen toestaan sommige HTML-tags in uw gegevens, bijvoorbeeld in reacties op uw site. WordPress biedt een reeks functies van het formulier wp_kses_ * (KSES Strips Evil Scripts). Deze functies verwijderen (een deel van de) HTML-tags en kunnen worden gebruikt om ervoor te zorgen dat koppelingen in de gegevens van opgegeven protocollen zijn. Bijvoorbeeld de wp_kses () functie accepteert drie argumenten:

inhoud - (string) Inhoud om door kses te filteren
allowed_html - Een array waarbij elke sleutel een toegestaan HTML-element is en de waarde een reeks toegestane kenmerken voor dat element is
allowed_protocols - Optioneel. Toegestaan protocol in koppelingen (bijvoorbeeld http, mailto, voeden enz.)

wp_kses () is een zeer flexibele functie, waarmee u ongewenste tags of alleen ongewenste attributen uit tags kunt verwijderen. Bijvoorbeeld om alleen toe te staan of tags (maar laat alleen het href-kenmerk toe):

$ content = "Klik hier te bezoeken wptuts+ "; echo wp_kses ($ content, array ('strong' => array (), 'a' => array ('href'))); // Drukt de HTML af" Klik hier om te bezoeken wptuts+ ": Klik hier om te bezoeken wptuts+

Uiteraard kan het specificeren van elke toegestane tag en elk toegestaan attribuut een moeizame taak zijn. Dus WordPress biedt andere functies die u kunt gebruiken wp_kses met vooraf ingestelde toegestane tags en protocollen - namelijk die worden gebruikt voor het valideren van berichten en opmerkingen:

wp_kses_post ()

wp_kses_data ()

De bovenstaande functies zijn nuttig om ervoor te zorgen dat HTML die van de gebruiker wordt ontvangen, alleen witte lijst-elementen bevat. Zodra we dat hebben gedaan, willen we er ook voor zorgen dat elke tag in evenwicht is, dat wil zeggen dat elke openingstag de bijbehorende afsluitende tag heeft. Hiervoor kunnen we gebruiken balanceTags (). Deze functie accepteert twee argumenten:

inhoud - Inhoud om tags van te filteren en in te delen

krachtbalans - Waar of niet waar, of het in evenwicht brengen van tags moet worden afgedwongen

 // Inhoud met ontbrekende sluiting  tag $ content = "Klik hier te bezoeken  wptuts + "; echo balanceTags ($ content, true), // Prints the HTML" Klik hier om te bezoeken  wptuts+ "

bestandsnamen

Als u een bestand in een van de mappen van uw website wilt maken, moet u ervoor zorgen dat de bestandsnaam zowel geldig als legaal is. Je zou ook willen zorgen dat de bestandsnaam uniek is voor die map. Hiervoor biedt WordPress:

sanitize_file_name ($ filename) - zuivert (of valideert) de bestandsnaam door karakters te verwijderen die illegaal zijn in bestandsnamen op bepaalde besturingssystemen of die op de commandoregel zouden moeten ontsnappen. Vervangt spaties met streepjes en opeenvolgende streepjes door een enkel streepje en verwijdert punten, streepjes en onderstrepingstekens vanaf het begin en einde van de bestandsnaam.

wp_unique_filename ($ dir, $ filename) - geeft een unieke terug (voor directory $ dir), gedesinfecteerde bestandsnaam (het gebruikt sanitize_file_name).

Gegevens uit tekstvelden

Wanneer u gegevens ontvangt die in een tekstveld worden ingevoerd, wilt u waarschijnlijk extra witte spaties, tabs en regeleinden verwijderen en alle tags verwijderen. Voor deze WordPress biedt sanitize_text_field ().

Keys

WordPress biedt ook sanitize_key. Dit is een zeer generieke (en soms nuttige) functie. Het zorgt er simpelweg voor dat de geretourneerde variabele alleen kleine letters, alfanumerieke tekens, streepjes en onderstrepingstekens bevat.

Data Sanitization

Terwijl validatie betrekking heeft op het valideren van gegevens, gaat data-sanering over het maken ervan veilig. Hoewel sommige van de hierboven genoemde validatiefuncties nuttig kunnen zijn om ervoor te zorgen dat gegevens veilig zijn - over het algemeen is dit niet voldoende. Zelfs 'geldige' gegevens kunnen in bepaalde contexten onveilig zijn.

Regel nr. 4: gegevens veilig maken gaat over de context

Simpel gezegd, je kunt het niet vragen "Hoe maak ik deze gegevens veilig?". In plaats daarvan zou je het moeten vragen, "Hoe maak ik deze gegevens veilig voor gebruik in X".

Om dit te illustreren, stel dat je een widget hebt met een tekstgebied waar je de gebruiker toestemming wilt geven om wat HTML in te voeren. Stel dat ze dan invoeren:

Hallo Wereld

Dit is perfect geldige en veilige HTML, maar als u op Opslaan klikt, zien we dat de tekst uit het tekstgebied is gesprongen. De HTML-code is niet veilig als een waarde voor het textarea:

Wat veilig is om in een bepaalde context te gebruiken, is niet noodzakelijk veilig in een andere. Telkens wanneer u gegevens gebruikt of weergeeft, moet u in gedachten houden welke vormen van sanering moeten worden getroffen om het gebruik van die gegevens veilig te maken. Daarom biedt WordPress vaak verschillende functies voor dezelfde inhoud, bijvoorbeeld:

de titel - voor het gebruik van de titel in standaard HTML (bijvoorbeeld binnen headertags)

the_title_attribute - voor gebruik van de titel als attribuutwaarde (meestal het titelkenmerk in -tags)

the_title_rss - voor het gebruik van de titel in RSS-feeds

Deze voeren allemaal de noodzakelijke sanering uit voor een bepaalde context - en als u ze gebruikt, moet u er zeker van zijn dat u de juiste gebruikt. Soms echter, moeten we onze eigen sanering uitvoeren - vaak omdat we aangepaste invoer hebben die verder gaat dan de standaard berichttitel, permalink, inhoud enz. Die WordPress voor ons verwerkt..

Ontsnappende HTML

Bij het afdrukken van variabelen naar de pagina moeten we rekening houden met hoe de browser ze zal interpreteren. Laten we het volgende voorbeeld beschouwen:

Veronderstellen $ title = . In plaats van de HTML te tonen
Sterker nog, als je dit doet, zou je het bijna zeker moeten gebruiken wp_localize_script () - die de ontsmetting voor u afhandelt. (Als iemand een reden kan bedenken waarom je misschien de bovenstaande methode zou moeten gebruiken, zou ik het graag willen horen).
Om het bovenstaande voorbeeld echter veilig te maken, kunt u de esc_js functie: Ontsnappen aan Textarea Bij het weergeven van inhoud in een tekstgebied, esc_html is niet voldoende omdat het doopt niet dubbel om entiteiten te coderen. Bijvoorbeeld:

 tekst stoutmoedig'?> <?php echo esc_html($var); ?> 
 $ var gedrukt in het tekstgebied zal verschijnen als:
  tekst stoutmoedig
 In plaats van ook de code te coderen & zoals & in de  labels.
 Voor deze WordPress biedt esc_textarea, die bijna identiek is aan esc_html, maar codeert entiteiten dubbel. In wezen is het weinig meer dan een verpakking voor htmlspecialchars. In dit voorbeeld:
  tekst stoutmoedig'?> <?php echo esc_textarea($var); ?> 
 Antispambot
 Het weergeven van e-mailadressen op uw website laat ze gevoelig voor e-mail harvesters. Een eenvoudige methode is om het e-mailadres te verbergen. WordPress biedt antispambot, die willekeurige delen van het e-mailadres codeert in hun HTML-entiteiten (en hexadecimale equivalenten indien $ mailto = 1). Op elke pagina moet de codering anders zijn en terwijl het geretourneerde adres correct wordt weergegeven in de browser, moet het als spannend voor de spambots worden weergegeven. De functie accepteert twee argumenten:
   e-mail - het adres om te versluieren
  mailto - 1 of 0 (1 bij gebruik van het mailto-protocol in een koppelingstag)

 $ email = "[email protected]"; $ email = sanitize_email ($ email); echo '' .antispambot ($ email). ' ';
 Vraagreeksen
 Als u variabelen uit een querytekenreeks wilt toevoegen (of verwijderen) (dit is erg handig als u gebruikers de mogelijkheid wilt geven om een bestelling voor uw berichten te selecteren), is het veilig en gemakkelijk om add_query_arg en remove_query_arg. Deze functies verwerken al het noodzakelijke ontsnappen voor de argumenten en hun waarden voor gebruik in de URL.
 add_query_arg accepteert twee argumenten:
   queryparameters - een associatieve array van parameters -> waarden
  url - de URL om de parameters en hun waarden aan toe te voegen. Als dit wordt weggelaten, wordt de URL van de huidige pagina gebruikt
 
 remove_query_arg accepteert ook twee argumenten, de eerste is een reeks parameters om te verwijderen, de tweede is zoals hierboven.
  // Als we zijn op www.example.com/wp-admin/edit.php?post_type=book $ query_params = array ('page' => 'my-bage'); $ url = add_query_arg ($ query_params); // Zou $ url instellen als: // www.example.com/wp-admin/edit.php?post_type=book&page=my-page
 
 Validatie & Sanitization
 Zoals eerder vermeld, is ontsmetting niet zo logisch zonder een context, dus het is vrij zinloos om gegevens te schonen wanneer u naar de database schrijft. Vaak moet je de gegevens toch in het onbewerkte formaat opslaan, en in elk geval - regel nr. 1 dicteert dat we altijd op output moeten opschonen.
 Validatie van gegevens moet daarentegen worden uitgevoerd zodra deze is ontvangen en voordat deze naar de database wordt geschreven. Het idee is dat 'ongeldige' gegevens automatisch worden gecorrigeerd, of worden gemarkeerd naar de gegevens, en dat alleen geldige gegevens aan de database moeten worden gegeven.
 Dat gezegd hebbende, wilt u misschien ook validatie uitvoeren wanneer gegevens ook worden weergegeven. In feite zorgt 'validatie' er soms ook voor dat de gegevens veilig zijn. Maar de prioriteit ligt hier bij veiligheid en u moet overmatige validatie vermijden die zou worden uitgevoerd bij elke pagina-belasting (de wp_kses_ * functies zijn bijvoorbeeld erg duur om uit te voeren).
 
 Database Ontsnappen
 Bij gebruik van functies zoals get_posts of klassen zoals WP_Query en WP_User_Query, WordPress zorgt voor de nodige sanering bij het opvragen van de database. Bij het ophalen van gegevens uit een aangepaste tabel of anderszins het uitvoeren van een directe SQL-query in de database, is de juiste ontsmetting dan aan u. WordPress biedt echter een nuttige klasse, de $ wpdb klasse, die helpt bij escaping SQL-query's.
 Laten we over deze basis nadenken 'SELECT'commando, waar $ leeftijd en $ voornaam zijn variabelen die een leeftijd en naam opslaan waar we naar vragen:
  SELECT * WHERE age = "$ age" EN voornaam = '$ voornaam'
 We zijn niet aan deze variabelen ontsnapt, dus mogelijk kunnen verdere opdrachten worden geïnjecteerd. Voorbeeld van xkcd van boven lenen:
  $ leeftijd = 14; $ firstname = "Robert"; DROP TABLE Students; "; $ sql = "SELECT * WHERE age =" $ age "AND firstname = '$ firstname';"; $ results = $ wpdb-> query
 Wordt uitgevoerd als de opdracht (en):
  SELECT * WHERE age = "14" AND voornaam = 'Robert'; DROP TABLE Studenten; ';
 En verwijder onze hele studententafel.
 Om dit te voorkomen, kunnen we de $ Wpdb-> bereiden methode. Dit accepteert twee parameters:
  De SQL-opdracht als een tekenreeks, waarbij tekenreeksvariabelen worden vervangen door de tijdelijke aanduiding % s en decimale getallen worden vervangen door de tijdelijke aanduiding % d en drijft voorbij % f 
 Een reeks waarden voor de bovenstaande tijdelijke aanduidingen, in de volgorde waarin ze in de query worden weergegeven
 
 In dit voorbeeld:
  $ leeftijd = 14; $ firstname = "Robert"; DROP TABLE Students; "; $ sql = $ wpdb-> prepare ('SELECT * WHERE age =% d AND firstname =% s;', array ($ age, $ firstname)); $ results = $ wpdb-> get_results ($ sql);
 De escaped SQL-query ($ sql in dit voorbeeld) kan dan worden gebruikt met een van de methoden:
  $ Wpdb-> get_row ($ sql)
 $ Wpdb-> get_var ($ sql)
 $ Wpdb-> get_results ($ sql)
 $ Wpdb-> get_col ($ sql)
 $ Wpdb->-query ($ sql)
 
 Gegevens invoegen en bijwerken
 Voor het invoegen of bijwerken van gegevens maakt WordPress het leven nog eenvoudiger door het $ Wpdb-> invoegen () en $ Wpdb-> update () methoden.
 De $ Wpdb-> invoegen () methode accepteert drie argumenten:
   Tafel naam - de naam van de tafel
  Gegevens - reeks gegevens die moet worden ingevoegd als kolom-> waardeparen
  formats - matrix van formaten voor de overeenkomstige waarden ('% s''% d'of'% f')
 
  $ leeftijd = 14; $ firstname = "Robert"; DROP TABLE Students; "; $ wpdb-> insert ('Students', array ('firstname' => $ voornaam, 'age' => $ age), array ('% s', '% d'));
 De $ Wpdb-> update () methode accepteert vijf argumenten:
   Tafel naam - de naam van de tafel
  Gegevens - reeks gegevens die moet worden bijgewerkt als kolom-> waardeparen
  Waar - reeks gegevens die moeten worden vergeleken als kolom-> waardeparen
  Data formaat - reeks indelingen voor de bijbehorende gegevenswaarden
  Waar formaat - matrix van indelingen voor de overeenkomstige 'waar'-waarden
 
  // Update Robert '; DROP TABLE Studenten; naar Bobby $ oldname = "Robert"; DROP TABLE Students; "; $ newname = "Bobby"; $ wpdb-> update ('Students', array ('firstname' => $ newname), array ('firstname' => $ oldname), array ('% s'), array ('% s'));
 Beide $ Wpdb-> invoegen () en de $ Wpdb-> update () methoden voeren alle noodzakelijke sanering uit om naar de database te schrijven.
 Zoals verklaringen
 Omdat het $ Wpdb-> bereiden methode gebruikt % om onderscheid te maken tussen de houders van de plaatsen, moet er voorzichtig mee worden omgegaan met het gebruik van de % wildcard in SQL LIKE-verklaringen. De Codex stelt voor om er met een seconde aan te ontsnappen %. Je kunt ook aan de term ontsnappen waar naar gezocht moet worden like_escape en voeg vervolgens het jokerteken toe % in voorkomend geval, voordat dit in de query wordt opgenomen met behulp van de bereidingsmethode. Bijvoorbeeld:
  $ Leeftijd = 14; $ firstname = "Robert"; DROP TABLE Students; "; SELECTEER * WAAR leeftijd = $ leeftijd (voornaam LIKE '% $ voornaam%');
 Zou worden veiliggesteld met:
  $ Leeftijd = 14; $ firstname = "Robert"; DROP TABLE Students; "; SELECTEER * WAAR leeftijd = $ leeftijd EN (voornaam LIKE '% $ voornaam%'); $ query = $ wpdb-> prepare ('SELECT * WHERE age =% d AND (firstname LIKE% s);', array ($ age, '%'. like_escape ($ firstname). '%'));
 
 Samenvatting
 Dit is geen uitputtende lijst van de functies die beschikbaar zijn voor validatie en ontsmetting, maar het moet de overgrote meerderheid van de use-cases dekken. Veel van deze (en andere) functies zijn te vinden in /wp-includes/formatting.php en ik raad ten stelligste aan om in de kerncode te graven en na te gaan hoe de kern van WordPress validatie en sanering van gegevens uitvoert.
 Heb je dit artikel nuttig gevonden? Heeft u nog meer suggesties over de beste werkwijzen voor gegevensvalidatie en -zuivering in WordPress? Laat het ons weten in de comments hieronder.



		
			
	   
	




Code