Trece mil sitios WordPress son hackeados cada día. No porque los desarrolladores de WordPress sean incompetentes, sino porque la arquitectura de la plataforma hace que la seguridad sea una responsabilidad que recae en cada autor de plugin, cada desarrollador de tema y cada administrador de sitio individualmente. Un plugin mal configurado, una dependencia desactualizada, un panel de administración expuesto -- y todo el sitio se compromete.
FLIN adopta un enfoque radicalmente diferente. La seguridad no es una funcionalidad que activas. No es un middleware que agregas. No es una biblioteca que instalas. Es una consecuencia del diseño del lenguaje en sí. Cada una de las diez categorías de vulnerabilidades del OWASP Top 10 se aborda a nivel de lenguaje, donde la corrección se aplica a cada aplicación automáticamente y no puede eludirse.
Este artículo recorre cada una de las diez categorías de vulnerabilidades y muestra exactamente cómo FLIN las elimina o mitiga.
La base de Rust
Antes de examinar vulnerabilidades individuales, vale la pena entender lo que FLIN hereda de su lenguaje de implementación. El runtime de FLIN está escrito en Rust, que elimina clases enteras de vulnerabilidades de seguridad de memoria en tiempo de compilación:
Desbordamientos de búfer -- Verificación de límites en compilación
Use-After-Free -- El sistema de propiedad lo previene
Double-Free -- Garantía de propietario único
Desreferencia de puntero nulo -- Option<T> fuerza manejo explícito
Carreras de datos -- El verificador de préstamos lo previene
Fugas de memoria -- Limpieza automática RAII
Punteros colgantes -- El sistema de tiempos de vida lo previene
Desbordamientos de enteros -- Verificados en debug, explícitos en releaseMicrosoft ha declarado que el 70% de todas las vulnerabilidades de seguridad en sus productos provienen de problemas de seguridad de memoria. Google encontró que el 70% de los errores de alta severidad de Chromium están relacionados con la memoria. Al elegir Rust para el runtime de FLIN, estas vulnerabilidades simplemente no existen. No se mitigan. No se reducen. Se eliminan.
A01: Control de acceso roto
El control de acceso roto es la vulnerabilidad número uno en el OWASP Top 10. Ocurre cuando una aplicación no impone quién puede acceder a qué.
En FLIN, el control de acceso es declarativo y se impone a nivel de enrutamiento:
flin// app/api/admin/users.flin
guard auth // Debe estar autenticado
guard role("admin") // Debe ser administrador
route GET {
User.all
}
route DELETE {
guard owner(params.id) // Debe ser propietario del recurso o administrador
user = User.find(params.id)
delete user
{ success: true }
}Los guards se evalúan antes de que se ejecute el manejador. No hay forma de eludirlos. No hay ruta de código que omita la verificación. Si el guard falla, la respuesta se envía y el manejador nunca se ejecuta.
El sistema de middleware proporciona protección a nivel de directorio:
flin// app/admin/_middleware.flin
middleware {
if session.user == none {
redirect("/login")
}
next()
}Cada archivo en el directorio admin/ está protegido. Agregar una nueva página de administración significa crear un archivo en ese directorio -- la protección se hereda automáticamente.
A02: Fallos criptográficos
Los fallos criptográficos ocurren cuando las aplicaciones usan algoritmos débiles, claves codificadas o no cifran datos sensibles.
Las funciones criptográficas integradas de FLIN usan algoritmos modernos y seguros por defecto:
flin// Hash de contraseña -- Argon2id por defecto (recomendación 2024)
hash = hash_password(password)
is_valid = verify_password(password, hash)
// Tokens JWT -- firmados con HMAC-SHA256 o RS256
token = create_token(user, { expires: "7d" })
claims = verify_token(token)
// Cifrado -- AES-256-GCM
encrypted = encrypt(data, key: env("ENCRYPTION_KEY"))
decrypted = decrypt(encrypted, key: env("ENCRYPTION_KEY"))No hay opción para usar MD5, SHA-1 o DES. No hay forma de crear un JWT sin firmar. No hay función que realice "cifrado" con codificación Base64. El algoritmo seguro es el único algoritmo.
A03: Inyección
La inyección SQL es la vulnerabilidad web más notoria. Ocurre cuando la entrada del usuario se concatena en consultas de base de datos.
FLIN hace imposible la inyección SQL porque FLIN no tiene SQL:
flin// FLIN: las consultas de entidad están parametrizadas por diseño
users = User.where(email == input_email)
// Se compila internamente a consulta parametrizada -- sin concatenación de cadenas
// Las consultas de intención analizan semántica, no concatenan cadenas
results = ask "users who signed up last week"
// La IA traduce la intención -- la entrada del usuario nunca se convierte en SQLNo hay función raw_query(). No hay forma de ejecutar SQL arbitrario. El sistema de consulta de entidades se compila a consultas parametrizadas en el runtime, y los parámetros se vinculan, no se interpolan.
La inyección XSS se previene de forma similar. Las plantillas de vista de FLIN escapan automáticamente toda la salida:
flinuser_input = "<script>alert('xss')</script>"
<p>{user_input}</p>
// Renderiza: <p><script>alert('xss')</script></p>A04: Diseño inseguro
El diseño inseguro cubre fallos arquitectónicos que no pueden corregirse con una implementación correcta. FLIN aborda esto a través de valores por defecto seguros:
flinentity User {
email: text @unique
password: text @hidden // Nunca se envía al cliente
role: text = "user" // Rol por defecto, no administrador
login_attempts: int = 0
locked_until: time?
}El decorador @hidden asegura que los hashes de contraseña nunca aparezcan en respuestas de API o plantillas de vista. El rol por defecto es siempre la opción de menor privilegio. Los campos de bloqueo de cuenta son parte del patrón de entidad, no una ocurrencia tardía.
A05: Configuración de seguridad incorrecta
La configuración de seguridad incorrecta ocurre cuando existen configuraciones seguras pero no están habilitadas. FLIN elimina esto eliminando la configuración por completo:
flin// No hay archivo de configuración de seguridad.
// Las cabeceras de seguridad son automáticas en producción.
// HTTPS es automático con Let's Encrypt.
// El modo de depuración está deshabilitado en producción.
// El listado de directorios está deshabilitado.
// Los rastros de pila se ocultan a los clientes.Cero configuración significa cero configuración incorrecta. El comportamiento seguro es el único comportamiento.
A06: Componentes vulnerables y desactualizados
La aplicación Express.js promedio tiene más de 400 dependencias transitivas. La instalación promedio de WordPress tiene docenas de plugins, cada uno con su propio árbol de dependencias. Cada dependencia es una vulnerabilidad potencial.
FLIN tiene cero dependencias de runtime:
Tamaño del binario FLIN: aproximadamente 15 MB
WordPress + Plugins: 500 MB - 2 GB
Dependencias de FLIN: 0 paquetes de runtime
Aplicación Express: más de 400 paquetes npmNo hay npm install. No hay composer require. No hay gestor de paquetes. No hay cadena de suministro. Todo el runtime es un solo binario compilado a partir de código Rust auditado.
A07: Fallos de identificación y autenticación
Los fallos de autenticación incluyen contraseñas débiles, falta de limitación de velocidad y credenciales expuestas. El sistema de autenticación integrado de FLIN aborda todo esto:
flinguard rate_limit(5, 60) // 5 intentos por minuto
route POST "/login" {
user = User.where(email == body.email).first
if user != none && user.locked_until != none && user.locked_until > now {
return error(423, "Account locked")
}
if user == none || !verify_password(body.password, user.password) {
if user != none {
user.login_attempts = user.login_attempts + 1
if user.login_attempts >= 5 {
user.locked_until = now + 15.minutes
}
save user
}
return error(401, "Invalid credentials")
}
user.login_attempts = 0
save user
create_session(user)
}La limitación de velocidad previene la fuerza bruta. El bloqueo de cuenta detiene el relleno de credenciales. La comparación de contraseña segura en tiempo previene ataques de temporización. El mismo mensaje de error para "usuario no encontrado" y "contraseña incorrecta" previene la enumeración de correos electrónicos.
A08: Fallos de integridad de software y datos
Esta categoría cubre ataques donde los recursos externos son manipulados -- secuestro de CDN, compromiso de CI/CD, actualizaciones sin firmar.
Las aplicaciones FLIN sirven todos los activos desde el mismo origen. No hay dependencias de CDN, no hay etiquetas de script externas y no hay descargas de paquetes en runtime. Las cabeceras de Content Security Policy se establecen automáticamente:
httpContent-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'Ningún script externo puede ejecutarse. Ninguna hoja de estilo externa puede cargarse. La superficie de ataque se limita al único binario FLIN.
A09: Fallos de registro y monitoreo de seguridad
Muchas aplicaciones no registran eventos relevantes para la seguridad, haciendo imposible detectar ataques o investigar brechas.
El modelo temporal de FLIN proporciona registro de auditoría automático para todos los cambios de entidad:
flin// Cada cambio de entidad se registra en el modelo temporal
user @ yesterday // ¿Cuál era el estado ayer?
user.history // Todos los cambios realizados a esta entidadLos eventos de autenticación se registran automáticamente. Intentos de inicio de sesión fallidos, inicios de sesión exitosos, cambios de contraseña, creación y destrucción de sesiones -- todo capturado sin ningún código del desarrollador.
A10: Falsificación de solicitudes del lado del servidor (SSRF)
Los ataques SSRF engañan al servidor para que realice solicitudes a recursos internos. Las funciones HTTP de FLIN validan URLs y bloquean direcciones internas:
flin// Configuración en flin.config
http {
allowed_domains = ["api.stripe.com", "api.sendgrid.com"]
block_internal = true // Bloquear 10.*, 192.168.*, localhost, 127.0.0.1
}
// Imposición en runtime
response = http_get(url) // Validado contra allowed_domainsLa configuración block_internal previene solicitudes a rangos de IP privados, localhost y direcciones link-local. Esto está habilitado por defecto. Una aplicación no puede usarse como proxy para escanear redes internas.
El efecto compuesto
Cualquier medida de seguridad individual puede ser eludida por un atacante determinado. El valor del enfoque de FLIN es el efecto compuesto: cada capa de la pila de aplicación se endurece simultáneamente. Rust elimina errores de memoria. Las consultas de entidad eliminan la inyección. Los guards eliminan fallos de control de acceso. Las cabeceras automáticas eliminan la configuración incorrecta. Cero dependencias eliminan ataques a la cadena de suministro. El modelo temporal elimina fallos de registro.
Un atacante necesitaría encontrar una vulnerabilidad que evada TODAS estas protecciones simultáneamente. Esa es una postura de seguridad fundamentalmente diferente a una instalación de WordPress donde cualquiera de los 70.000 plugins puede comprometer todo el sistema.
En el próximo artículo, profundizamos en una característica de seguridad específica: el hash de contraseñas Argon2, el algoritmo que FLIN usa por defecto para cada contraseña en cada aplicación.
Esta es la Parte 106 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abiyán y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.
Navegación de la serie: - [105] Helpers de respuesta y códigos de estado - [106] Seguridad por diseño: OWASP Top 10 en el lenguaje (estás aquí) - [107] Hash de contraseñas Argon2 integrado en FLIN - [108] Autenticación JWT en 3 líneas de FLIN