3

In a lot of how to create a custom meta box tutorials, when saving data, i.e., update_post_meta the data is escaped:

update_post_meta( $post_id, 'city', esc_attr( ucwords( $_POST['city'] ) ) ); 

Some tutorials do not esc when saving and do it on screen output.

However, escaping protects the output to the screen, i.e., echo:

echo esc_attr( $city );

So does it matter if you esc before you output to the screen or before it's saved?

If you esc on save does the order of esc-ing, sanitizing and validating matter?

Do you esc then sanitize and validate or sanitize, esc and sanitize . . . etc.?

4

Yes it does. Escaping depends on context and in worst case like using esc_html when writing directly to the DB are just a security hole.

Even if there is no security issue, there is theoretical one. The user asked you to store A, and you are storing B. In a simple cases B is exactly how A should be displayed in the HTML, but life is rarely simple and while at one point you want to display A in an input for which you want to do esc_attr and at another in a textarea for which you will want to use esc_html. If you already transformed A into B in the DB, it is a PITA to reconstruct for B what was the original A to apply the correct escape function on it.

Rule of thumb: In the DB you should store the raw values the user submitted (probably sanitized, but not escaped), escaping should be done only on output.

2

Input from the user or other functions etc you validate and sanitize. For sanitizing sql strings before execution (important one!) look at this page http://codex.wordpress.org/Data_Validation under Database. When you want to sanitize input from a not trusted source then sanitize look under text input or use http://codex.wordpress.org/Function_Reference/sanitize_text_field which is also on the first page under text nodes. Now you can more safely use sql strings crafted dynamically in your scripts and store them safely in a database. The thing about esc_html is only for the browser and to display symbols like & which also can be seen as code and displayed incorrectly, nothing more.

If you want to be sure that you always use the same data then json_encode it UNICODE, convert it to a base64 string and than store it or send it.

  • 1
    "json_encode it UNICODE, convert it to a base64" great trick! even though it adds a little space it is quite awesome. – Samuel Elh May 23 '16 at 0:19
  • 1
    this is the way twitter public streaming api and other larger websites with api's do send strings and objects from api to endpoint so I did not think of it myself. I use it for sure sometimes – Daniel Mulder May 23 '16 at 15:25
  • 1
    I am surprised!! I was only limited to using json_encode(), now totally going for the base64 conversion. Thank you! – Samuel Elh May 23 '16 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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