I was doing a few tweaks to the Twitter Embed plugin earlier today and found out that authors that access to the custom fields interface could exploit them to print unfiltered HTML. This happened because I cached the HTML retrieved from the Twitter API in an unprotected meta field to the post.
The easiest workaround was to add an underscore prefix to the meta key, so my_meta_key for example, would become _my_meta_key. For a second though, I thought that somebody might type in the underscore in the custom fields interface too, so I spent a few minutes reading the admin ajax source code.
It turns out that there is a call to a function called is_protected_meta defined in meta.php, which does the check for the preceding underscore, so the custom fields interface will not allow working with protected meta fields no matter on what user level, which is good! It still allows themes and plugins to use get_post_meta and update_post_meta.
So the lesson learned today — if you’re storing sensitive data in your post meta fields, don’t forget to protect them from eyes by prefixing your meta keys with underscores.
