1

I've always known that it's good practice to sanitize GET and POST data. I usually do this globally in my functions file with code like this:

$_POST  = filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);
$_GET  = filter_input_array(INPUT_GET, FILTER_SANITIZE_STRING);

With plugins that have a Settings screen, using the recommended code for plugins according to the plugin API, is it necessary to sanitize user inputs on the plugin's Settings page, like checkboxes, text fields, etc?

Or does the Plugin API take care of POST/GET sanitization on plugin Settings screens?

Note that using the above code block gives me the message "your link has expired" when saving plugin options (via the "Save" button on the plugin's settings screen).

What is the best practice for sanitizing plugin settings?

3
  • Not sure I understand why there would be issues with sanitizing POSTS/GETS. Seems to me that would be a good practice, in addition to sanitizing individual POST/GET data (which I also do). If sanitizing the POST/GET causes an error, maybe that's a good thing. Commented Feb 1, 2022 at 2:52
  • 1
    Sorry, I should've said "I would not" and not "don't", and therefore I deleted that comment. But let me say it in this way, "I would not modify superglobals unless it's absolutely the only possible way to sanitizing the values" - softwareengineering.stackexchange.com/q/76406. And WordPress core does modify POST and GET variables, but only to add slashes, so " for example becomes \", but other sanitization like stripping HTML tags are to be done or handled manually by plugins and themes.
    – Sally CJ
    Commented Feb 1, 2022 at 3:27
  • 1
    See my answer below. Thanks. Commented Feb 2, 2022 at 22:55

1 Answer 1

0

Here's what I found out, with appreciation for the comments to the question.

I write WP code (themes and plugins) and non-WP PHP code (for non-WP sites). In non-WP sites, I include those statements in my 'include' file to ensure POST/GET sanitation, even though I try to sanitize the fields elsewhere. So, sort of a 'sanitize backup plan'.

But putting the code in a WP plugin file too soon kills the plugin's settings screen and/or the front end; more often on the front end with the plugin enabled (result is sometimes a white screen).

So, for WP plugins/themes, I will ensure sanitization of individual POST/GET fields, rather than the above code.

In non-WP sites, though, the above code is benign - sort of a double-check-sanitation thing, even though I try to remember to sanitize POST/GET fields before using that data.

1
  • 1
    "for WP plugins/themes, I will ensure sanitization of individual POST/GET fields, rather than the above code" - Yes and I initially recommended doing that because WordPress can be extended by plugins and themes via various hooks, so we don't know if the data should all be sanitized (using the same sanitization function or method) - what if a plugin/theme needs to access the original, unsanitized/raw data? How would they retrieve it when for example HTML and/or new lines in the superglobals were already removed (by your code)?
    – Sally CJ
    Commented Feb 3, 2022 at 1:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.