Si eres «desarrollador» o «programador», «developer», «full stack», «full stock», «Petete» o como te quieras denominar (que para gustos colores), debes tener muy en cuenta que la seguridad del código que desarrolles es algo muy importante y una gran responsabilidad.

Si tu plugin está disponible en el repositorio oficial de WordPress, tu código puede ser utilizado por millones de personas, o (lo más probable) por unas decenas o cientos de personas. Pero la responsabilidad es la misma si tu plugin está siendo utilizado por un solo cliente, pero su web tiene millones de visitas, quizás muchos miles sean bots, hackers o aprendices de malvados con mucho tiempo libre, y ahí está tu responsabilidad. Responsabilidad frente a los datos de tu creación y también de todo un sistema que se puede comprometer por tu ausencia de seguridad en lo que has desarrollado.

Vamos a ver algunos consejos que deberías tener en cuenta, desde luego que ni son todos ni cumpliendo estas recomendaciones ya podremos decir que nuestro plugin es seguro, pero por algo se empieza.

Rock And Roll All Nite

Que dirían los chicos de Gene Simmons, o mejor dicho, KISS, pero no, no hablamos del fantástico grupo de los 70, sino del principio de mantener las cosas lo más sencillas posibles (Keep it simple, stupid).

Cuanto más complicamos un código, más difícil de mantener acaba siendo y más propenso a todo tipo de fallos, entre ellos, fallos de seguridad.

English pitinglish aunque solo hables castejano

Sí, tenemos la mala suerte de no pertenecer a un país anglosajón y si programamos, como esto del código viene de los americanos, -los del norte, Canadá no, no tan al norte-, no nos queda más remedio que escribir en inglés, y no del de la Gran Bretaña (sino que se lo digan a los del color vs colour entre otras palabras made in USA).

Y esto es así, porque nuestro código puede ser utilizado tanto en Galicia como en Andalucía o Cataluña, pero también en Texas, Sidney, Kioto, Durban o Milán. Y debe ser entendido por todos ¿y qué tiene esto que ver con la seguridad?, bueno, yo creo que mucho. Ante un fallo del siguiente plugin:

$最大歌曲數 = 999;

$max_number_of_songs = 999;

¿De cuál de las dos sentencias anteriores nos será más fácil encontrar un error en la variable? ¿Y cuál de las dos versiones es más propensa a introducir un error que acabe siendo un fallo de seguridad?

Y no me digas que tu código solo lo vas a modificar tú o solo se va a utilizar en España, que como decía mi abuela, esas son excusas de mal pagador.

El código en WordPress se traduce desde el inglés como idioma base a todos los demás idiomas. Las constantes, variables, funciones, clases, métodos, etc. deben de nombrarse en inglés y de paso utilizar un nombrado coherente; para la variable anterior ni utilices $maximum_number_of songs_that_the_database_can_contain_to_limit_the_integer_to_be_used ni $mnos

Donde dije digo, digo digo

Y no Diego, es decir, coherencia a lo largo del código. Si obtienes datos de usuario con una función tipo get_user() no obtengas información del tiempo con una función que se llame obtain_forecast(). Sé coherente y para obtener datos utiliza siempre get y en este caso get_forecast().

Si tenemos una nomenclatura en todo nuestro código, es más, en todos nuestros desarrollos, seremos mucho menos propensos a introducir errores en el código y ante un error será más fácil localizarlo y arreglarlo.

Y volviendo al principio KISS, que cada función o método sea tan simple que haga solo una cosa. Si hace dos cosas tienes un problema, porque se debería de tratar de dos funciones (métodos, interfaces, etc.). Si tu función realiza varias tareas, refactoriza para dividirlo en varias funciones y que cada una realice una única tarea, lo más sencilla posible (¿recuerdas a Gene Simmons o quizás a Paul Stanley? Pues eso KISS).

Que tu código sea muy prepotente

Bueno, no era prepotente, pero para el título quedaba mejor que este palabrejo «idempotente» que viene a significar algo así: que por muchas veces que lo ejecutemos, nos dé siempre el mismo resultado.

Y desde luego que la Idempotencia también aporta seguridad a nuestro código, ya que evita consecuencias inesperadas y fuera de nuestro control.

Crear un código idempotente no es tarea fácil y podríamos decir que va para máster de programación, pero si quieres tomarte muy en serio la seguridad y sobre todo la excelencia en tu código, es un término que debes explorar en profundidad y refactorizar tu código y la lógica del mismo hasta lograrlo.

Si al ejecutar un código nos funciona como lo habíamos programado, pero la siguiente vez que se ejecuta, no lo hace o nos desconfigura algo de lo anteriormente realizado, estamos ante un desastre y un evidente problema de seguridad.

Escapa tarde que no hay prisa

Pues eso, que hagas Late Scaping o escapes los textos, variables, traducciones y demás lo más tarde posible, normalmente en el momento de mostrarlo al usuario. Si escapamos un texto pronto, al efectuar modificaciones del mismo, por ejemplo enviarlo a otro método para que lo transforme, se pueden introducir en el mismo efectos indeseables. Por eso, debemos escapar lo más tarde posible (Late Scaping), normalmente en el momento de mostrarlo por pantalla o devolver su valor:

echo esc_html( $results_text );

Valida lo antes posible

Lo dicho, valida lo antes posible (justo al contrario que el escapado). Nunca creas al usuario o los datos que llegan de terceras partes. Como me decía mi abuela, nunca creas nada de lo que te digan y de lo que veas, créete la mitad. Pues en el código, más de lo mismo.

Valida todo lo que venga de una API externa, de las traducciones (no sabemos qué puede haber en los archivos po traducidos de otros idiomas), de los formularios de usuario, de la Base de Datos… de cualquier sitio, no te creas nada.

Lo que hagas con la validación ya depende un poco de tu estrategia, lo que debe hacer el código, etc.; por ejemplo, un formulario que te enviará una dirección de correo electrónico. Si lo que te llega no es un correo electrónico (a pesar de que el campo HTML era type=”email” y lo validaste también con JavaScript), puedes directamente eliminar el texto recibido y decirle al usuario que es incorrecto o utilizar un mail por defecto. También puedes informar del error de entrada al usuario y darle la oportunidad de arreglarlo o parar la ejecución del código y devolver un error.

Con estas dos secciones debemos quedarnos con que «nunca debemos creer al usuario, validar lo antes posible y escapar lo más tarde posible».

No todos somos iguales, aún hay niveles

Que diría alguno… es decir, roles (niveles) de usuario. Cada usuario tiene unos determinados roles con unas capacidades de acciones que puede realizar y otras que no. Usémoslas.

Si nuestro plugin permite realizar un volcado de la Base de datos, está claro que esa acción no debería estar disponible a todos los usuarios, por ejemplo los editores de la web, que puedan volcar la base de datos completa y se produzca una fuga de datos con graves consecuencias.

Antes de realizar algunas acciones, comprueba si el usuario tiene los permisos suficientes para realizarla, ya sea mediante el rol de usuario o mediante las capacidades específicas.

Aunque un determinado menú solo esté disponible para los administradores, cuando realizamos la acción que debe tener especial cuidado, debemos comprobar de nuevo si puede realizar dicha acción y cuenta con los privilegios suficientes.

¿Seguro que vienes de parte de mi amigo?

Es decir, has llegado a esta página de guardado de los datos del formulario, pero ¿seguro que vienes de mi página de formulario y no de otra fake?

Bien, para asegurarnos, utiliza siempre, SIEMPRE los números de un solo uso (es un decir, en realidad se utilizan más de una vez), es decir, los nonces.

Utiliza los nonces para las peticiones AJAX, en los formularios, para las páginas que vienen «de parte de otra» (por ejemplo, dónde se elimina un usuario o posts en el backend) y siempre que debamos asegurarnos del origen legítimo. Pero además, combínalo con los roles de usuario y capacidades, no permitas borrar un usuario solo porque viene del origen correcto, aunque el usuario actual no tenga la capacidad de delete_users.

Escapa otra vez

Si vas a guardar algo en la Base de Datos. La inyección SQL es uno de exploits más frecuentes en el código y en WordPress podemos evitarla preparando toda consulta que vaya a ser ejecutada en la base de datos.

Esto lo realizamos con $wpdb->prepare(). 

Debemos darle un repaso en profundidad al objeto wpdb que dispone de muchas opciones para interactuar con la base de datos y obtener los datos que nos interesan y no recuperar todas las columnas de una tabla y después solo mostrar una columna (get_col).

¿Y ahora qué?

De momento solo hemos arañado la superficie de la seguridad en nuestro código.

Utiliza siempre, siemPRE, SIEMPRE los estándares de WordPress.

Utiliza PHPCS para que tu código tenga 0 fallos, cero, no solo dos o uno, cero.

Pero no creas que porque tu código da cero errores en PHPCS ya es seguro, ni mucho menos.

No te pongas excusas a ti mismo: este plugin solo lo voy a utilizar yo, es para un sitio pequeño, nadie lo va a modificar, este dato va a ser siempre un número entero, el presupuesto para este desarrollo es muy bajo y no puedo pararme con los nonces… las excusas son solo excusas y en cuanto a la seguridad del código, no valen NUNCA.

Utiliza ayudas para mantener tu código más seguro.

Ayúdate de las excelentes herramientas de IA que tenemos, pero igual que al usuario, no las creas NUNCA. Usa su código solo después de probar cada carácter y entender al 100% lo que hace. Son un becario excelente a un precio de risa, pero tú eres el senior y debes verificar el más mínimo código que genere la IA, es tu responsabilidad.

Y ya puestos, además de tener muy en cuenta la seguridad de tu código, programa teniendo en cuenta desde el minuto uno la accesibilidad y la usabilidad. La optimización del código para obtener el máximo rendimiento posible también debe abarcarse desde el inicio, nos son tareas a ejecutar al finalizar nuestro código. Todas estas son tareas a realizar en paralelo para que nuestro código sea seguro, veloz, accesible y usable, porque, recuerda CODE IS POETRY.