Revisar la puerta antes de abrirla al público

El problema

La mayoría de los proyectos web salen a producción confiando en que nadie mire con demasiado cuidado. La seguridad queda como un paso opcional al final, cuando ya no hay presupuesto ni ganas, y el resultado es predecible: una clave escrita dentro del código, un formulario que acepta cualquier cosa, un portal donde cambiando un número en la dirección se ven los datos de otro cliente.

Nada de eso se nota el día del lanzamiento. Se nota meses después, cuando alguien lo encuentra. Y en un portal con datos personales o pagos, encontrarlo tarde sale caro.

Cómo funciona

Es el mismo procedimiento en toda entrega, en tres momentos:

• Se construye seguro. Mientras se escribe el sistema aplican reglas fijas: dónde viven las claves, qué se valida antes de guardarlo, cómo se separan los datos de un cliente de los de otro.
• Se revisa contra una lista. Antes de cada entrega se pasa una verificación de dieciséis áreas —claves, permisos, límites de uso, registros, dependencias, servidores, datos personales— con cuatro niveles de gravedad. Lo grave bloquea el lanzamiento.
• Se ataca a propósito. Se somete el sistema a herramientas que buscan fallas: claves filtradas en el historial, librerías con problemas conocidos, pruebas contra el sitio ya montado.

El cliente recibe eso por escrito: qué quedó cerrado, qué sigue abierto y por qué. Una regla no se negocia: nunca se ataca un sistema en producción sin permiso escrito de su dueño; las pruebas agresivas van contra una copia.

Qué cambió

Salir a producción dejó de ser un acto de fe. El cliente no recibe la promesa de que “quedó seguro”, recibe una lista revisada. Y la seguridad dejó de ser la línea del presupuesto que se recorta primero: viene incluida, con la profundidad que amerite el riesgo. Un sitio informativo no necesita lo mismo que un portal con pagos.

Qué más se puede hacer con esto

• Portales de clientes: verificar que ningún cliente pueda ver lo de otro, la falla más común y la más costosa.
• Tiendas en línea: proteger las cuentas, los cupones y la conexión con las pasarelas de pago.
• Apps con datos personales: consentimiento, plazos de borrado y registro de quién consultó qué.
• Plataformas con pagos: mantener las tarjetas fuera del propio servidor, lo que evita una auditoría anual costosa.

Bajo el capó

El marco de referencia es el OWASP Top 10, adaptado al terreno local: pasarelas colombianas, sistemas administrativos de cliente y bastante servidor propio. Hay guías por tecnología y detalles que solo se conocen habiéndose quemado: por ejemplo, la diferencia entre una regla de base de datos que filtra lo que un usuario ve y otra que además controla lo que puede escribir.