¿Qué es la ciberseguridad?

La ciberseguridad es el trabajo de mantener los sistemas digitales confiables cuando las personas, el software y las redes hacen cosas que no esperabas.

Esa definición es amplia a propósito. Puede incluir fraude bancario, malware, phishing, infraestructura en la nube, defensa de redes, privacidad, respuesta a incidentes y una decena de especialidades más. Este manual no pretende cubrir todo eso.

Este manual trata sobre seguridad de aplicaciones para desarrolladores: la seguridad del código que escribes, revisas y despliegas.

Juno¿Qué es la ciberseguridad? La ciberseguridad es una palabra grande, pero este manual la mantiene pegada al código. Nos importa el campo de formulario que alguien edita, el registro de pedido que alguien solicita, el token que prueba quién es esa persona, y la ruta a la que se llama demasiadas veces.

Con eso basta para empezar. No tienes que aprender cada especialidad de seguridad de una sola vez.

Juno¿Qué es la ciberseguridad? La ciberseguridad abarca muchísimo terreno. La porción útil aquí es la seguridad de aplicaciones: los puntos donde una solicitud, un usuario, un registro de base de datos o un token se encuentran con el código que despliegas.

Eso mantiene el trabajo concreto. Si puedes reproducir el bug cambiando una ruta, un body, una cookie, un token, un esquema o una ruta de middleware, pertenece a este manual.

Juno¿Qué es la ciberseguridad? El límite aquí es deliberado: seguridad de aplicaciones, no toda la industria de la seguridad. La prueba es si la falla viene de código, configuración o flujo de datos que un desarrollador puede razonar, cambiar y probar con pruebas de regresión.

Eso todavía deja mucho por romper: inyección, identidad, autorización, disponibilidad, secretos y logs. El malware, la defensa de redes y el cumplimiento normativo pueden llevar sus propios registros aparte. Este ya tiene suficientes aristas filosas.

Eso significa que nos importan preguntas como estas:

• ¿Qué pasa si un usuario cambia un campo oculto del formulario antes de enviarlo?
• ¿Puede un cliente leer el pedido de otro cliente?
• ¿Qué pasa si se filtra un token de inicio de sesión?
• ¿Se puede llamar a una ruta miles de veces hasta que la aplicación se ponga lenta?
• ¿El servidor verifica los datos, o solo confía en el navegador?

¿Por qué estas preguntas?

Todas ocurren dentro del código base, la API, la consulta a la base de datos, la cookie de sesión y el esquema de validación. Esa es la parte de la ciberseguridad hecha a la medida de un desarrollador, que es lo que enseña este manual.

Cómo llegamos hasta acá

La palabra es más nueva que el problema. Las computadoras empezaron como máquinas compartidas en laboratorios, luego pasaron a oficinas, hogares, teléfonos y sistemas de pago. Cuando el software empezó a manejar dinero, identidad y registros privados, romper el software dejó de ser una broma y se convirtió en una forma de robar, espiar, interrumpir o suplantar identidad.

La web agudizó ese cambio. Un navegador es una puerta de entrada amigable, pero envía texto que tu servidor tiene que interpretar: URLs, headers, cookies, formularios, cuerpos JSON, subidas de archivos.

Cada solicitud es una pequeña historia que el navegador le cuenta a tu servidor, y el servidor tiene que decidir cuánto de esa historia creerle.

Por qué los desarrolladores la necesitan

Los primeros sitios web eran básicamente documentos. Visitabas una página, la leías, hacías clic en un enlace y seguías de largo. Las aplicaciones web modernas son distintas. Procesan pagos, almacenan datos personales, gestionan identidad, llaman a APIs, suben archivos y toman decisiones en nombre de los usuarios.

Una función normal puede convertirse en un bug de seguridad cuando confía en lo que no debe. Un cuadro de búsqueda puede convertirse en un punto de inyección. Una página de perfil puede filtrar los datos de otra persona. Un botón útil para exportar datos puede convertirse en un problema de denegación de servicio si una sola solicitud le pide a la base de datos demasiado trabajo.

La buena noticia es que la mayor parte de esto se puede aprender. No necesitas convertirte en criptógrafo ni en ingeniero de redes para escribir código de backend más seguro. Necesitas unos cuantos hábitos:

• Fijarte por dónde entra la información al sistema.
• Verificar las decisiones en el servidor.
• Tratar la identidad y los permisos como preguntas separadas.
• Pensar en qué podría salir mal antes de lanzar la función.
• Conocer lo suficiente las clases comunes de bugs como para reconocerlas.

Ese es el camino que sigue este manual.

JunoPor qué los desarrolladores la necesitan Un bug de seguridad suele ser una función normal que confía en lo que no debe. El navegador dice este pedido es mío. La URL dice este registro es mío. La solicitud dice este precio cuesta tres dólares.

El servidor tiene que preguntarse: "¿Yo mismo sé eso con certeza?". Esa sola pregunta carga con buena parte del curso.

JunoPor qué los desarrolladores la necesitan Las aplicaciones modernas son límites de seguridad porque toman decisiones: quién puede ver un registro, qué acción está permitida, si un dato es válido y cuánto trabajo puede pedir una sola solicitud.

Regla práctica: encuentra la decisión y luego encuentra los datos que usó. Si los datos vinieron del navegador, de un token, de otro servicio o de un registro viejo en la base de datos, haz que el servidor lo compruebe antes de confiar en ellos.

JunoPor qué los desarrolladores la necesitan La mayoría de los bugs de seguridad en aplicaciones son bugs comunes de flujo de control, solo que con un llamador hostil en la sala. La rama se ejecutó, la consulta devolvió resultado, el middleware dejó pasar la solicitud, y aun así falló el invariante porque el valor que decidía vino del lado equivocado del límite de confianza.

La versión de producción es aburrida y útil: coloca el control donde se hace cumplir el invariante, prueba el camino malo y deja evidencia para la siguiente persona que se pregunte por qué existe esa verificación.

El camino desde aquí

El camino empieza con una idea simple: el código seguro empieza por cómo pensamos.

Por eso la primera sección empieza con STRIDE y OWASP. STRIDE te ayuda a preguntarte qué podría salir mal mientras una aplicación todavía se está diseñando. OWASP te da nombres para los bugs que aparecen una vez que las aplicaciones reales ya están funcionando en el mundo.

Primero construimos la mentalidad, y luego pasamos al trabajo concreto de desarrollo: entrada de datos no confiable, XSS, inyección SQL, validación, autenticación, tokens, OAuth, límites de tasa y throttling.

JunoEl camino desde aquí Los primeros capítulos tratan de aprender las preguntas. ¿Qué podría salir mal? ¿De quién viene esta solicitud? ¿Qué le está permitido tocar a este usuario? ¿Qué pasa si la entrada es hostil?

Después de eso, los capítulos convierten esas preguntas en código.

JunoEl camino desde aquí El orden importa. STRIDE te da preguntas para el momento del diseño, OWASP te da nombres para bugs que ya están en producción, y luego el triage convierte un hallazgo en impacto, prioridad y siguiente acción.

Después de eso, el recorrido aplica el mismo ciclo a la entrada de datos, la identidad y el tráfico. La solución se recuerda más fácil cuando queda ligada al bug que previene.

JunoEl camino desde aquí El camino es un ciclo de trabajo: predecir las fallas antes de construir, reconocer las que llegan a producción, decidir cuáles importan primero y luego retroalimentar esa lección en el siguiente diseño.

Los capítulos posteriores son casos concretos de ese mismo ciclo: intérpretes, sistemas de identidad, permisos, volumen de solicitudes y evidencia operacional. Mismo café, nuevo modo de falla.

## Lo que este manual no es

Esto no es un recorrido completo por la ciberseguridad. No cubrimos análisis de malware, herramientas de pentesting, defensa de redes, marcos de cumplimiento normativo ni operaciones de seguridad.

Esos temas importan. Están fuera del trabajo que hace este manual.

El trabajo aquí es más acotado y más práctico: ayudarte a construir aplicaciones de backend más difíciles de usar mal, más fáciles de razonar y más seguras de poner frente a usuarios reales.

JunoLo que este manual no es Dejar temas afuera es parte de lo que hace útil a este manual. Nos quedamos con el código que puedes abrir, leer y cambiar.

Eso significa rutas, esquemas, cookies, tokens, consultas y middleware. Hay mucho que aprender, sin pretender que un solo manual pueda enseñar cada campo de la seguridad.

JunoLo que este manual no es El alcance es la seguridad de aplicaciones para desarrolladores de backend. Eso mantiene cada capítulo cerca de una ruta, un esquema, una cookie, un token, una consulta, una función de middleware o una configuración de despliegue que puedas inspeccionar.

Cuando un tema necesita un SOC, una captura de paquetes, un programa de cumplimiento normativo o un laboratorio de malware, queda fuera de este recorrido. Es útil, pero no es el trabajo que hace este manual.

JunoLo que este manual no es El alcance acotado es justamente lo que le da fuerza al manual. Un recorrido amplio nombraría cada campo de la seguridad y no enseñaría ninguno bien, que es exactamente cómo terminas con una lista de verificación que nadie se hace responsable de mantener.

Este recorrido sigue los sistemas que un desarrollador de backend puede cambiar, revisar y probar: manejo de solicitudes, identidad, autorización, validación, throttling, almacenamiento e higiene operacional.

Hacia dónde va esto

La palabra quedó acotada: seguridad de aplicaciones, el código que escribes, revisas y despliegas. El alcance está definido, y las preguntas que vale la pena hacerse ya están sobre la mesa.

Lo que falta es el hábito de hacerlas. Cómo pensar en seguridad es donde empieza eso, con los límites de confianza y el reflejo de mirar tu propio código como lo haría alguien con malas intenciones.