La seguridad de las aplicaciones que construimos y operamos — controles escritos en código, verificables externamente, sin certificaciones que no tenemos.
El trabajo abarca la seguridad de la aplicación y la ingeniería de la confidencialidad: encabezados y política de contenido, limitación de tasa, posición predeterminada «cerrado» de las verificaciones, cifrado de secretos, registros que no se pueden reescribir, anonimización de datos y plazos de conservación puestos en código, no solo en la política. No somos auditores certificados y no emitimos certificados.
Ya construidoAm ales „livrat” pentru un domeniu deliberat îngust, iar limita o scriem înaintea listei de capabilități. Controalele descrise mai jos rulează în sisteme proprii și o parte se pot verifica din exterior chiar acum: limitarea de rată se demonstrează cu douăsprezece cereri consecutive (a zecea primește 429, verificat pe producție la 06.09.2026), sonda de sănătate întoarce doar valori logice, iar antetele de securitate se citesc din răspuns. A doua și a treia implementare citate sunt platforma de sesizări — politică de conținut cu valoare unică per răspuns, listă albă de destinații de rețea verificată în integrarea continuă, autentificare în doi pași obligatorie pentru personal — și clientul de semnătură electronică scris fără nicio dependență nouă, cu apărare împotriva încadrării semnăturii XML. Ce NU susține dovada: nu avem nicio certificare, nu facem testare ofensivă ca serviciu, nu operăm un centru de monitorizare și nu emitem atestate de conformitate.
La mayoría de los fallos que encontramos en nuestros propios sistemas no fueron explotaciones sofisticadas. Fueron valores por defecto. Una ruta que iniciaba una llamada telefónica a cualquier número, sin autenticación, que ningún componente de la interfaz había vuelto a usar desde hacía tiempo. Una comprobación de origen que pasaba cuando la lista estaba vacía. Una dirección IP completa enviada en un mensaje de notificación, mientras la página pública prometía anonimización. Las tres estaban escritas en nuestro código y ninguna se habría visto en un escáner automático.
De aquí viene la forma del servicio. No vendemos un informe de escaneo. Leemos el código con una pregunta precisa: cuando esta verificación no puede decidir, qué hace — permite o rechaza? La posición implícita es la diferencia entre un gate y una decoración. En nuestros sistemas, el gate de consumo devuelve «no permitido» ante una excepción, y la ruta de llamada telefónica responde 404 si el secreto no está configurado — es decir, la función está apagada si alguien no la ha activado deliberadamente.
La segunda mitad del trabajo es la ingeniería de la confidencialidad, porque en la práctica ambas no se separan. El plazo de conservación declarado públicamente no significa nada si no lo aplica el código. En nuestro caso, el registro de solicitudes borra los archivos más antiguos que el plazo declarado, con el número de días tomado del mismo valor que aparece en la política publicada. En otro sistema, la tabla de retención mantiene junto a cada plazo el texto publicado, palabra por palabra, y la base legal — para que la política y la base de datos no puedan desviarse una de otra en silencio.
Lo que publicamos sobre nosotros mismos es parte del método. La política de contenido de este sitio permite `unsafe-inline` y `unsafe-eval` en scripts. Es una debilidad real y la escribimos aquí, no en un informe interno: fue precisamente el mecanismo por el cual nuestra propia auditoría de accesibilidad pudo inyectar una herramienta de verificación directamente en la página de producción. Un proveedor que no publica sus propias debilidades conocidas no puede encontrar las tuyas.
Qué incluye
El trabajo, por componentes
Leemos la posición por defecto de cada comprobación
La pregunta central del análisis: cuando la verificación no puede decidir, ¿permite o rechaza? Ejemplo real, de nuestro propio código, marcado como tal: la lista de orígenes permitidos de un widget deja pasar la verificación si la lista está vacía — elección deliberada de compatibilidad con las instalaciones antiguas, escrita en el comentario, pero que significa que la restricción por dominio debe configurarse explícitamente en cada implementación. Contraejemplo: el gate de consumo que ante cualquier excepción devuelve «no permitido».
Limitación de tasa correcta detrás de un proxy
Diez solicitudes por minuto por dirección, con una sutileza que decide si el límite funciona o no: la clave se toma del último salto del encabezado de redirección, no del primero. Nuestro proxy añade la dirección real al final de lo que envió el cliente, así que la primera entrada la controla el atacante — quien la use como clave puede superar su límite enviando valores aleatorios. Se puede verificar externamente: doce solicitudes consecutivas dan nueve respuestas correctas, luego 429.
Encabezados y política de contenido, con valor único por respuesta donde se puede
En este sitio: transporte estricto durante dos años con subdominios e inscripción en la lista de precarga, tipo de contenido no deducible, política de referencia restringida, política de permisos que cierra la cámara y deja el micrófono y la localización solo para la página propia. En la plataforma de reclamaciones, más estricto: la política de contenido recibe un valor único en cada respuesta, generado en el proxy, sin fuentes de terceros para scripts, conexiones o fuentes, y la inclusión en un marco se rechaza por completo.
Lista blanca de destinos de red, verificada automáticamente
En un proyecto público, qué direcciones tiene permiso de contactar la aplicación es una lista verificada por un comando ejecutado en integración continua, tanto de forma estática como en ejecución. Un paquete nuevo que empieza a llamar a casa falla en la verificación, no en producción. Es el control que detecta exactamente la clase de incidentes de la cadena de suministro contra la que nadie se protege con un escáner de vulnerabilidades.
Los secretos no llegan a respuestas, registros ni notificaciones
La sonda de salud del formulario de contacto devuelve solo valores lógicos — si está configurado, si la credencial es válida, si el registro se puede escribir — nunca el token, el identificador de la conversación ni el nombre del bot. Los tokens de canal de la plataforma de mensajería se guardan cifrados. Los registros de alerta pasan por un módulo de redacción de datos personales antes de escribirse.
Anonimización aplicada antes de escribir, no después
La dirección IP se trunca al prefijo de red — /24 para IPv4, /48 para IPv6 — antes de entrar en el registro o en una notificación. Con dos detalles que importan: se toma el último salto, no el primero, por la misma razón que en la limitación de tasa; y las direcciones IPv4 reportadas en forma mapeada IPv6 se reconocen y se tratan como IPv4, de lo contrario se conservarían completas, es decir, exactamente al revés del propósito.
Registro que añade, no reescribe
Las solicitudes mediante formulario se escriben en un registro de adición, un objeto por línea, con permisos 0600 para el archivo y 0700 para el directorio, antes de intentar la entrega. El motivo es un fallo real: cuando cayó el canal de notificación, el endpoint devolvía 500 y cada solicitud se perdía sin rastro. Ahora un canal roto significa «hay que mirar el archivo», no «la solicitud nunca existió». El resultado de la entrega se escribe como una segunda línea, con el mismo identificador.
El plazo de conservación aplicado por el código, no solo declarado
El registro de solicitudes borra los archivos más antiguos que el plazo declarado públicamente, con el número de días tomado del mismo valor. En otro sistema, la tabla de retención mantiene junto a cada plazo el texto publicado palabra por palabra y la base legal, y la función de limpieza informa por defecto de lo que borraría; el borrado real exige un argumento explícito. El borrado en silencio es un modo de fallo, no una función.
La identidad y la firma, cuando el proyecto las requiere
Tenemos escritos, desde cero y sin dependencias nuevas, un proveedor de servicios para autenticación federada y un cliente para firma electrónica. El analizador de XML no procesa definiciones de tipo de documento, así que la clase de ataques por entidades externas no se aplica; la verificación de firma devuelve el nodo cubierto por la firma, no un valor lógico, y el llamador está obligado a comparar la identidad del objeto — la defensa contra el wrapping de firma. La canonicalización se verificó con los vectores oficiales de la especificación.
Qué aspecto tiene
El recorrido, paso a paso.
01
Definimos el alcance y lo que no podemos tocar
Por escrito, antes de cualquier comando: qué sistemas, qué período, qué tipos de verificación están permitidos y quién es la persona de contacto si algo se detiene. Entregamos: el documento de alcance firmado y la lista de sistemas excluidos.
02
Leemos el código y la configuración, con énfasis en la posición por defecto
Las comprobaciones que no pueden decidir, los secretos que llegan a respuestas o registros, las rutas que ya no llama nadie pero siguen abiertas, los encabezados faltantes. Entregamos: los hallazgos con archivo y línea, ordenados por lo que se puede hacer con ellos, no por la severidad teórica.
03
Reparamos o describimos exactamente la reparación
Donde tenemos acceso, ponemos el control y escribimos la prueba que lo mantiene en su sitio — una verificación que no tiene prueba se pierde a la primera refactorización. Donde no tenemos acceso, entregamos la modificación descrita con suficiente precisión para que el equipo del cliente pueda aplicarla sin volver a preguntarnos.
04
Vinculamos la confidencialidad con el código
El plazo de conservación, la anonimización y la lista de destinatarios se convierten en valores en el código, con el texto publicado al lado. Entregamos: el registro de tratamientos completado, con la columna «dónde está implementado» llena, y la lista de los puntos que quedan por decidir, con quién decide cada uno.
05
Verificamos desde fuera lo que se puede verificar desde fuera
Los encabezados, el comportamiento al límite, lo que devuelven las sondas de salud. Entregamos: los comandos exactos de verificación, para que cualquiera — incluido un auditor del cliente — pueda repetir la verificación sin nosotros.
Straturile pe care le atingem, de sus în jos
Los datos
Qué tocamos, dónde están y cuánto se quedan
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Qué tocamos en un análisis
El código, la configuración del servidor, las cabeceras de respuesta y, cuando corresponde, el esquema de la base de datos y las políticas de acceso, línea por línea. No necesitamos los datos reales de los clientes para hacer el análisis y preferimos no tocarlos en absoluto.
Qué no hacemos sin un dominio autorizado por escrito
Ninguna acción que produzca tráfico contra un sistema en funcionamiento. Las verificaciones en producción que aparecen en esta página son solicitudes habituales de lectura, en sistemas propios. Cualquier superación de este límite requiere una autorización escrita, con período y direcciones, firmada por quien tiene derecho a darla.
Dónde van a parar las conclusiones
En un documento con una conclusión por línea: dónde está, qué se puede hacer con ella, qué la corrige y cómo se verifica la corrección. Las conclusiones que describen una vía de explotación no circulan por canales no seguros y no llegan a materiales públicos antes de la reparación.
Registro de tratamientos
Para la parte de confidencialidad, el resultado es un registro con una línea por actividad: finalidad, base, categorías de datos, destinatarios, transferencias, ubicación del almacenamiento, plazo, medidas y el archivo del código donde está implementado. Lo que no se pudo verificar se escribe «neverificat», no se completa a partir de una plantilla.
La regla que mantiene la política pegada al código
Si un cambio de código modifica qué se recopila, a quién llega o cuánto se conserva, la política publicada se modifica en el mismo paso de entrega. La divergencia entre la política publicada y el código fue exactamente el problema que nos hizo escribir nuestro propio registro.
Un caso
Una ruta olvidada que podía llamar a cualquiera
La situación
En una revisión de nuestro propio sitio encontramos una ruta de interfaz de programación que iniciaba una llamada telefónica a cualquier número enviado en el cuerpo de la solicitud. Sin autenticación, a costa de la empresa y desde el número de la empresa. Ningún componente de la interfaz la llamaba ya — el único llamador era un elemento que ya no se mostraba. Es decir, había funcionado abierta a internet sin que nadie tuviera motivo para mirarla.
Qué construimos
La tratamos como dos problemas, no uno. Técnicamente: la ruta ahora requiere un secreto compartido en una cabecera, y si el secreto no está configurado en absoluto responde 404 — la capacidad está apagada si alguien no la enciende deliberadamente, no encendida hasta que alguien la apaga. Jurídica y éticamente: una llamada automática no solicitada es un tratamiento de datos que la persona llamada no pidió, así que escribimos en el registro lo que haría falta para una eventual reactivación — base documentada respecto a la persona llamada, evidencia del consentimiento y un canal de oposición.
Qué salió
La capacidad está cerrada por defecto y permanece cerrada hasta que alguien tome una decisión explícita. La línea del registro de tratamientos describe el estado, lo que había antes, el riesgo y las condiciones de reactivación — así, la siguiente persona que encuentre la ruta no tiene que reconstruir el razonamiento.
Qué no dice el caso
No nos dimos cuenta de esto con una herramienta. La encontramos leyendo las rutas una por una y preguntando, para cada una, quién la llama. Un escáner automático habría visto una ruta que devuelve 400 ante una solicitud vacía y habría seguido adelante. También es la limitación del método: cubre lo que leemos, y lo que no leemos queda sin cubrir — por eso el dominio se establece por escrito.
Preguntas
Lo que nos pregunta la gente antes de llamar
¿Tienen certificaciones de seguridad?
No. Ni ISO 27001, ni SOC 2, ni una certificación de pruebas ofensivas, ni acreditación de auditor. No emitimos certificados ni firmamos atestaciones de conformidad. Lo que podemos mostrar es la práctica propia, con archivo y línea, y los controles que hemos puesto en sistemas en funcionamiento. Si necesitas un certificado para un dossier, necesitas un organismo acreditado, no a nosotros — y es mejor que lo sepas ahora.
¿Hacen pruebas de penetración?
No como servicio. No tenemos equipo de pruebas ofensivas, licencia ni metodología certificada, y no fingimos que la tenemos. Lo que hacemos es análisis del código y de la configuración, además de comprobaciones no invasivas desde el exterior — cabeceras, el comportamiento al límite de tasa, lo que filtran las respuestas de error. Si el proyecto requiere pruebas ofensivas reales, necesitas una empresa especializada; podemos trabajar junto a ella en la parte de remediación.
¿Qué habéis encontrado en vuestros propios sistemas?
Tres cosas, en un solo día de análisis, todas escritas públicamente en nuestro registro. Una ruta que iniciaba una llamada telefónica a cualquier número del cuerpo de la solicitud, anónima, sin autenticación, que ningún componente de la interfaz volvía a invocar — ahora responde 404 si el secreto no está configurado, es decir, se apaga si alguien no la pone en marcha deliberadamente. Un widget de conversación que se cargaba en cada vista y escribía la sesión en la memoria del navegador antes de que el visitante pidiera nada — ahora se carga al pulsar el botón. Y la dirección IP completa enviada en una notificación, mientras la página pública prometía anonimización — ahora se trunca antes de escribirse.
Vuestra política de contenido permite `unsafe-eval`. ¿Por qué debería creeros?
Porque te lo dijimos nosotros, no lo descubriste tú. Sí, la política de este sitio permite `unsafe-inline` y `unsafe-eval` en scripts: es una debilidad real, heredada de la forma en que se cargan ciertos scripts de terceros, y es precisamente el mecanismo por el cual nuestra propia auditoría de accesibilidad inyectó una herramienta de verificación en la página de producción. En un proyecto donde la restricción la ponemos nosotros desde el principio, la forma correcta es la de la plataforma de reclamaciones: valor único por respuesta generado en el proxy y ninguna fuente de terceros para scripts. La diferencia entre las dos es exactamente la conversación que deberíamos tener al principio de un proyecto, no al final.
¿Cómo verifico yo, sin creeros a ciegas, que la limitación de tasa funciona?
Enviando doce solicitudes consecutivas a una ruta de interfaz de programación de este sitio y contando las respuestas: las primeras nueve pasan, la décima recibe 429 con la cabecera que dice dentro de cuánto tiempo se puede reintentar. La ventana es de un minuto. El comando está en la lista de fuentes de esta página y puedes ejecutarlo ahora. El mismo principio lo aplicamos a lo que entregamos: si un control no se puede verificar desde el exterior por el cliente, no está entregado, está declarado.
¿Qué ocurre con los datos personales de un formulario?
Se escriben en un registro en modo de adición, un objeto por línea, con permisos restringidos sobre el archivo y el directorio, antes de intentar la entrega — para que un canal de notificación roto no haga que la solicitud desaparezca. La dirección IP se trunca al prefijo de red antes de escribirse. Los archivos más antiguos que el plazo declarado se eliminan, con el número de días tomado del mismo valor que aparece en la política publicada. Y la fila del registro de tratamientos dice, para cada elemento, en qué archivo del código está implementado.
¿Podéis hacer autenticación con identidad electrónica estatal o firma electrónica?
El código existe y está probado, pero no está activado en ninguna parte de producción, y la diferencia importa. Tenemos escrito un proveedor de servicios para autenticación federada y un cliente de firma, ambos sin dependencias nuevas, con las defensas específicas implementadas y con pruebas. Lo que falta no depende del código: contrato con la autoridad, certificado de sistema y registro de la dirección de producción. Hasta entonces, la variante que funciona hoy es aquella en la que el ciudadano firma en el portal oficial y sube de nuevo el documento firmado.
¿Qué controles ponéis normalmente en una nueva aplicación?
Cabeceras y política de contenido con valor único por respuesta; limitación de tasa con la clave tomada correctamente desde detrás del proxy; separación por organización aplicada en la base, no solo en la aplicación; secretos cifrados y nunca en respuestas ni registros; claves de idempotencia en los eventos de terceros; autenticación en dos pasos obligatoria para las cuentas del personal; registro de auditoría con visibilidad separada para interno y público; y, para los proyectos públicos, una lista blanca de destinos de red verificada automáticamente en cada entrega.
¿Qué no cubre este servicio?
La seguridad de la red corporativa, los equipos de los usuarios, la monitorización continua de tipo centro de operaciones, la respuesta a incidentes 24/7, la investigación forense y la formación contra phishing. No son cosas que hagamos mal — son cosas que no hacemos. Nuestro ámbito es la aplicación que construimos o asumimos, más los datos que pasan por ella.
En qué se basan las afirmaciones anteriores (24 fuentes)
Antete pe producție: transport strict 63072000 s cu subdomenii și precarcare, tip de conținut nedeductibil, politică de referință restrânsă, politică de permisiuni care închide camera; încadrarea în cadru e refuzată complet pe rutele de interfață de programare și limitată la aceeași origine pe paginihttps://www.megapromoting.com/api/health/contact · 2026-09-06
22 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.