## Undocumented use of a 3rd Party or external service
We permit plugins to require the use of 3rd party (i.e. external) services, provided they are properly documented in a clear manner.
We require plugins that reach out to other services to disclose this, in clear and plain language, so users are aware of where data is being sent. This allows them to ensure that any legal issues with data transmissions are covered. This is true even if you are the 3rd party service.
In order to do so, you must update your readme to do the following:
- Clearly explain that your plugin is relying on a 3rd party as a service and under what circumstances
- Provide a link to the service .
- Provide a link to the service terms of use and/or privacy policies.
Example(s) from your plugin:
# Domain(s) mentioned in the readme file. Links to service terms and/or privacy policy not found.
plugin v1.0.2/includes/post-scheduler.php:92 wp_remote_post('https://plexorin.com/hub/operations/api-blog-content-scheduler.php', array('method' => 'POST', 'body' => wp_json_encode($data), 'headers' => array('Content-Type' => 'application/json')));
plugin v1.0.2/js/main.js:39 url: 'https://plexorin.com/hub/operations/api-verify-key',
## Variables and options must be escaped when echo'd
Much related to sanitizing everything, all variables that are echoed need to be escaped when they're echoed, so it can't hijack users or (worse) admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data, as well as some that will allow you to echo HTML safely.
At this time, we ask you escape all $-variables, options, and any sort of generated data when it is being echoed. That means you should not be escaping when you build a variable, but when you output it at the end. We call this 'escaping late.'
Besides protecting yourself from a possible XSS vulnerability, escaping late makes sure that you're keeping the future you safe. While today your code may be only outputted hardcoded content, that may not be true in the future. By taking the time to properly escape when you echo, you prevent a mistake in the future from becoming a critical security issue.
This remains true of options you've saved to the database. Even if you've properly sanitized when you saved, the tools for sanitizing and escaping aren't interchangeable. Sanitizing makes sure it's safe for processing and storing in the database. Escaping makes it safe to output.
Also keep in mind that sometimes a function is echoing when it should really be returning content instead. This is a common mistake when it comes to returning JSON encoded content. Very rarely is that actually something you should be echoing at all. Echoing is because it needs to be on the screen, read by a human. Returning (which is what you would do with an API) can be json encoded, though remember to sanitize when you save to that json object!
There are a number of options to secure all types of content (html, email, etc). Yes, even HTML needs to be properly escaped.
https://developer.wordpress.org/apis/security/escaping/
Remember: You must use the most appropriate functions for the context. There is pretty much an option for everything you could echo. Even echoing HTML safely.
Example(s) from your plugin:
plugin v1.0.2/admin/settings-page.php:61 <img src="<?php echo plugins_url('../img/default.webp', __FILE__); ?>" style="width: 100%">
-----> echo plugins_url('../img/default.webp', __FILE__);
plugin v1.0.2/admin/settings-page.php:83 <img src="<?php echo plugins_url('../img/default.webp', __FILE__); ?>" style="width: 100%">
-----> echo plugins_url('../img/default.webp', __FILE__);
plugin v1.0.2/admin/settings-page.php:72 <img src="<?php echo plugins_url('../img/default.webp', __FILE__); ?>" style="width: 100%">
-----> echo plugins_url('../img/default.webp', __FILE__);