Secure my “add_settings_field” translation?

1 Views

I am using “add_settings_field” and want to provide translation for it , but my problem is security.
So is __('My Checbox:' , 'domain') secure enough for translation?

If not what can I do about it?

Read More

I have tried to use esc_html_e( 'My Checbox:' , 'domain' )
and esc_html_( 'My Checbox:' , 'domain' ) but it breaks my page… 

add_settings_field(
   'add_checkbox',
    __('My Checbox:' , 'domain'),<!--Is this secure when translating?-->    
   'my_checkbox_function',
   'theme_options',
   'theme_options'
   );
Post Views: 1

Related posts

Leave a Reply

1 comment

  1. No, it is not. Use esc_html__( 'string', 'text_domain' ) instead (two underscores).

    Translated strings are unknown input. Unknown input is per default malicious.

    • You don’t know where the language file comes from. It doesn’t even have to be the one you provided, because the path can be filtered or changed with a symlink.
    • Even if it is your file: do you have control over the whole process from creation to delivery? You cannot control the wordpress.org repo for example, the same is true for GitHub and other repositories in other people’s hands.
    • Have you actually looked at the string; do you get “funny characters”? What looks funny in your editor/browser might be a dangerous output depending on the encoding. Do you control the encoding of the page? Probably not.
    • You could get around of these problem by using a checksum, a hash of the original file that you compare before you load the translation. But then again, that hash has to be stored somewhere, and that place might be writable too.

    Always make your output as safe as possible. If you don’t want HTML in a string, do not allow it. If you get errors, analyze the error messages and fix those errors, do not loose up security.