1) Unsanitized input (issue found in approx. 99% of first reviews)

Sanitizing is important to prevent the possibility of XSS vulnerabilities and MITM attacks.

This affects any data that is being read from any of these PHP global variables $_POST / $_GET / $_REQUEST / $_COOKIE / $_SERVER / $_SESSION / $_FILES (the file name)

We will request you to sanitize any of these variables in the code and also do it as soon as possible (before storing it in another variable or doing something else with it).

These are the standard WordPress functions for sanitizing https://developer.wordpress.org/apis/security/sanitizing/ . Other options like using filter_input( INPUT_POST, 'prefix_post_id', FILTER_SANITIZE_NUMBER_INT ); or abs($_POST['prefix_post_id']); are ok too.

Example of incorrect lines (corrected version immediately below
$post_id = $_POST['prefix_post_id'];
$post_id = absint( $_POST['prefix_post_id'] );

$post_title = isset( $_POST['prefix_post_title'] ) ? $_POST['prefix_post_title'] : '';
$post_title = isset( $_POST['prefix_post_title'] ) ? sanitize_title( $_POST['prefix_post_title'] ) : '';

$user_email = wp_unslash( $_POST['prefix_user_email'] );
$user_email = sanitize_email( $_POST['prefix_user_email'] );

if ( ! isset( $_POST['prefix_nonce'] ) || ! wp_verify_nonce( $_POST['prefix_nonce'] , 'prefix_nonce' ) )
if ( ! isset( $_POST['prefix_nonce'] ) || ! wp_verify_nonce( sanitize_text_field( wp_unslash ( $_POST['prefix_nonce'] ) ) , 'prefix_nonce' ) )

How to detect this:
You can use the tool "WordPress Coding Standards for PHPCS" or just find any $_POST / $_GET / $_REQUEST / $_COOKIE / $_SERVER / $_SESSION / $_FILES variable on your code and wrap it with an appropriate sanitization function.

Special situations:
In some cases your plugin will need to sanitize an array, you can do that easily using array_map() , for example:
$post_id_array = array_map( 'absint', (array) $_REQUEST['prefix_post_id_array'] );
$city_names_array = map_deep( $_POST['city_names_array'], 'sanitize_text_field' );

For multidimensional arrays with different data types, you may have to create your own sanitize function.

2) Unescaped output (issue found in approx. 99% of first reviews)

Escaping is essential to prevent XSS vulnerabilities and breaking with the structure of the HTML document.

This affects any content that is being output in any way that PHP / WordPress allows such as with echo , print , printf , _e , _ex among others.

We will request you to escape any of these variables in the code and also do it as late as possible (immediately before being echoed).

These are the standard WordPress functions for escaping https://developer.wordpress.org/apis/security/escaping/
Other options that obviously limit the introduction of code like echo abs( $post_id ); are ok too.

Example of incorrect lines (corrected version immediately below):
echo '<h1>' . $title . '</h1>';
echo '<h1>' . esc_html($title) . '</h1>';

<input value="<?php echo $value ?>" type="text">
<input value="<?php echo esc_attr($value) ?>" type="text">

printf('<a href="%s">%s</a>', $url, $text);
printf('<a href="%s">%s</a>', esc_url($url), esc_html($text));

echo '<h1>' . prefix_process_title(esc_html($title)) . '</h1>';
echo '<h1>' . esc_html(prefix_process_title($title)) . '</h1>';

<h2><?php _e('Settings page', 'plugin-slug'); ?></h2><br /><h2><?php esc_html_e('Settings page', 'plugin-slug'); ?></h2>

How to detect this:
You can use the tool "WordPress Coding Standards for PHPCS" or just find any echo , print , printf on your code and wrap any variable element inside it with an appropriate escaping function as late as possible.

In case of the _e or _ex functions, use an alternative function that escapes the output, like esc_html_e or esc_attr_e , or simply use __ or _x functions wrapped by a escaping function and inside an echo .

Special situations:
In some cases, your plugin will need to echo HTML code. To do that, you can make use of wp_kses_post or wp_kses . The function wp_kses_post will allow any common HTML that can go inside a post content, wp_kses will allow any HTML that you set up using its second and third parameters, please refer to its documentation.
Examples: echo wp_kses_post($html_content); or echo wp_kses($html_content, 'post'); or echo wp_kses($html_content, array( 'a', 'div', 'span' )); 

Also, the plugin might need to echo a JSON object. To do this, instead of using json_encode($value); you can use wp_json_encode($value); which sanitizes the output.

3) Missing or incorrect plugin and readme headers (issues found in approx. 70% of first reviews)

Plugins must have the required parameters in the readme and the plugin headers in order to be displayed properly in the repository and to the users.
This is documented in these links:
• https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/
• https://developer.wordpress.org/plugins/plugin-basics/header-requirements/

Incorrect "Tested up to" parameter (readme file):
This should be the major version of WordPress that this plugin has been tested on. In the case of new plugins, we require it to be the latest version. This is necessary for plugins to be visible in the repository.
Example: Tested up to: 6.3 

Stable tag (readme file) does not match Version tag (plugin header):
These values need to match the current version of the plugin, and they need to be exactly the same.

Example:
Stable tag: 1.0.0
Version: 1.0.0

For example, this would be wrong, as 1.0 != 1.0.0
Stable tag: 1.0
Version: 1.0.0

Setting up the parameter "Update URI" (plugin header):
Just don't do that for plugins hosted in the WordPress.org repository, it doesn't make sense.

Failure to disclose third party or external services (readme file):
Any usage of third party services, such as connecting to an external API, needs to be documented in the readme file.

How to document this:
• Clearly explain that your plugin is relying on a third party service and under what circumstances.
• Provide a link to the service.
• Provide a link to the service's terms of use and/or privacy policies.
There is no specific format for this, but please make sure you provide enough info and links to terms of use / privacy policies.

4) Missing or inadequate function prefixes (issue found in approx. 60% of first reviews)

All active plugins in a WordPress installation will be loaded during execution. When two elements use the same name, a collision will happen. With more than 80k plugins in the repository, collisions are increasingly common.

That's why we need plugins to prefix their: function names, class names, namespaces, defines, option names, nonces and own input names with something that is related to this plugin, sufficiently complex and at least 5 characters long.

Example: a plugin named "Moon forms" could choose "moofor_ " or "moonforms_ " as a prefix but "mf_ ", "moon_ " or "forms_ " would be bad choices as they are too short, too generic or both.

This rule applies not only to function and class names (where namespaces are the best alternative) but also to defines, saving options, nonces and own input names, for example:
function moonforms_submit_button(){
class Moonforms_Form {
namespace Moonforms\Submit;

define('MOONFORMS_PLUGIN_URL', plugin_dir_url(__FILE__) );
define('MOONFORMS_PLUGIN_DIR', plugin_dir_path(__FILE__) );

update_option( 'moonforms-default-email', $email );

wp_nonce_field( 'moonforms-form', 'moonforms-nonce' );
if ( !empty( $_POST['moonforms-nonce'] ) && wp_verify_nonce( sanitize_text_field( wp_unslash ( $_POST['moonforms-nonce'] ) ), 'moonforms-form' ) ) {

<input name="moonforms-email" type="email">
$email = sanitize_email( $_POST['moonforms-email'] );