El pineado de certificados es un control de seguridad de red que impide la interceptación casual del tráfico, pero puede eludirse en un dispositivo que el atacante controla, por lo que debe ser una capa más y no una garantía. En el marco de OWASP corresponde al control MASVS-NETWORK, y su verificación se describe en la MASTG. La diferencia entre ambos estándares es clave: la MASVS define qué requisitos de seguridad debe cumplir la app, mientras que la MASTG explica cómo probarlos. Prueba el pineado solo en tu propia app, en un dispositivo aislado, y refuérzalo con validación en el servidor, ya que la protección duradera está del lado del servidor.
Respuesta rápida
El pineado de certificados protege frente a la interceptación en dispositivos normales, pero es eludible en un dispositivo con root, así que trátalo como defensa en profundidad. Según la MASTG de OWASP, las pruebas de comunicación de red se realizan sobre tu propia app, y el control corresponde a MASVS-NETWORK en la MASVS. La distinción entre ambos es esencial: la MASVS es el estándar de requisitos, es decir, qué debe cumplir la app, y la MASTG es la guía de pruebas, es decir, cómo verificarlo. Prueba solo tu app en un dispositivo aislado, mantén la lógica sensible en el servidor y no confíes en el pineado como única defensa.
Qué es el pineado de certificados
El pineado de certificados hace que tu app confíe únicamente en un certificado o clave pública concretos del servidor, en lugar de en cualquier certificado que aceptaría el almacén de confianza del sistema. Esto bloquea un método de interceptación habitual, en el que un atacante coloca un proxy con su propio certificado entre la app y el servidor, porque la app rechaza ese certificado al no coincidir con el fijado. Para intentos casuales en un dispositivo normal, el pineado funciona bien.
Es eludible porque la comprobación se ejecuta dentro de tu app, en el dispositivo. En un dispositivo que el atacante controla por completo, como un teléfono con root, puede observar y modificar el comportamiento de la app en tiempo de ejecución, incluida la parte que realiza la comprobación del pineado. Así, la misma propiedad que protege a un usuario normal, una comprobación dentro de la app, es la que permite anularla en un dispositivo bajo control total del atacante.
MASVS vs MASTG: la diferencia
La diferencia entre la MASVS y la MASTG es la del qué frente al cómo. La MASVS, el Mobile Application Security Verification Standard, es el estándar que define los requisitos de seguridad que una app móvil debería cumplir, organizados por categorías como almacenamiento, criptografía, autenticación, red, plataforma, código y resiliencia. Responde a la pregunta de qué controles debe tener la app.
La MASTG, el Mobile Application Security Testing Guide, es la guía que explica cómo probar esos requisitos, con casos y técnicas de prueba concretos. Responde a la pregunta de cómo verificar que la app cumple lo que la MASVS exige. Son complementarias: la MASVS establece el objetivo y la MASTG proporciona el método para comprobarlo, de modo que se usan juntas, una para definir el nivel de seguridad y la otra para verificarlo de forma reproducible.
Qué control de OWASP aplica
El pineado de certificados corresponde a MASVS-NETWORK, la categoría de la MASVS dedicada a la comunicación de red segura. Este control abarca que la app establezca canales seguros, valide correctamente los certificados y, cuando proceda, fije el certificado o la clave del servidor. Cuando revisas el pineado de tu app frente a un estándar, es este control el que aplica.
La verificación práctica se apoya en la MASTG, que describe cómo probar la comunicación de red y la resistencia del pineado sobre tu propia app. Así, MASVS-NETWORK indica qué debes lograr y la MASTG indica cómo comprobarlo. Mapear tu pineado a MASVS-NETWORK te da un criterio claro para saber si el control está presente y bien implementado, más allá de que simplemente exista alguna comprobación en el código.
Condiciones conocidas de bypass
El pineado del lado del cliente puede anularse porque, en un dispositivo controlado, nada de lo que hace la app queda realmente oculto para quien posee el dispositivo. Mediante instrumentación en tiempo de ejecución, se puede reemplazar el comportamiento de la comprobación, de modo que una función que rechazaría un certificado no confiable se fuerce a aceptarlo. Ninguna astucia en la comprobación elimina esto, porque sigue ejecutándose en un entorno bajo control del atacante.
Es la misma clase de limitación que cualquier control del lado del cliente en un dispositivo que el atacante posee. No hace inútil el pineado, que sigue deteniendo la interceptación en dispositivos normales y sin modificar, lo que cubre buena parte de las amenazas reales. Pero sí significa que el pineado no es una barrera frente a un atacante decidido en su propio dispositivo con root, y suponer que un secreto viaja seguro solo porque la app fija el certificado es el error a evitar.
Cómo probarlo de forma segura
Prueba únicamente tu propia app, en un dispositivo o emulador que controles, en un entorno aislado y con la debida autorización. El objetivo es medir la resistencia de tu pineado: comprobar si un bypass en tiempo de ejecución lo desactiva, si tu app detecta o resiste esa manipulación y si alguna acción sensible sigue teniendo éxito una vez eludido el pineado. Cada hallazgo señala una mejora concreta.
Mantén el trabajo dentro de su alcance y orientado a la remediación, tal como describe la MASTG para probar la comunicación de red de tu propia app. La finalidad no es producir un bypass reutilizable, sino entender la resistencia de tu control para decidir cuánto confiar en él y qué añadir a su lado. Documenta lo que encuentres en tu app, corrige las brechas y vuelve a probar, que es como una prueba de seguridad autorizada se convierte en una app más sólida.
Remediación recomendada
La remediación consiste en tratar el pineado como una capa dentro de un diseño de defensa en profundidad. Implementa el pineado correctamente para que bloquee la interceptación en dispositivos normales, pero no dependas de él como única protección. Valida y autoriza las operaciones sensibles en tu servidor, donde el atacante no tiene control, de modo que una comprobación del cliente eludida no conceda por sí sola acceso ni exponga datos. Mantén los secretos y la lógica de confianza fuera del cliente.
Puedes añadir detección de manipulación y de root para elevar el esfuerzo, pero reconoce que también son controles del lado del cliente que un atacante decidido puede eludir, por lo que son obstáculos y no muros. La protección duradera proviene del servidor y de no depositar en el cliente más confianza de la que un dispositivo controlado puede recibir. El pineado encaja en ese diseño como una capa valiosa, no como toda la defensa.
MASVS y MASTG comparadas
Ver ambos estándares en paralelo aclara cómo se usan juntos. La tabla siguiente los compara.
| Aspecto | MASVS | MASTG |
|---|---|---|
| Qué es | El estándar de requisitos de seguridad | La guía de pruebas de seguridad |
| Qué responde | Qué debe cumplir la app | Cómo verificar que lo cumple |
| Contenido | Controles por categoría, como MASVS-NETWORK | Casos y técnicas de prueba concretos |
| Uso en el pineado | Define el requisito de red seguro | Describe cómo probar el pineado |
Lee la tabla como una guía de uso conjunto. La MASVS fija el objetivo y la MASTG aporta el método, de forma que primero decides qué controles exigir y luego usas las pruebas para confirmarlos de manera reproducible.
Lista de verificación
Una comprobación breve convierte estos límites en acciones. La lista siguiente cubre lo esencial.
| Verificación | Acción | Hecho |
|---|---|---|
| Implementar el pineado | Como capa frente a la interceptación | [ ] |
| No depender solo del cliente | Validar las acciones sensibles en el servidor | [ ] |
| Secretos fuera del cliente | Mantener la lógica de confianza en el servidor | [ ] |
| Probar tu propia app | Pruebas autorizadas en un dispositivo aislado | [ ] |
| Mapear a MASVS-NETWORK | Verificar el control y probarlo con la MASTG | [ ] |
Las dos que más importan son la validación en el servidor y mantener los secretos fuera del cliente, porque se sostienen aunque se eluda el pineado. El pineado y la detección de manipulación añaden coste al atacante, pero la protección duradera está en el servidor, al que un dispositivo con root no llega.
Verifica con un escáner
Decidir los controles correctos es una parte; confirmar que están presentes en lo que distribuyes es otra, sobre todo cuando el pineado o las protecciones de red pueden faltar sin que se note en el código. La verificación es lo que separa una app que crees segura de una que has comprobado.
Un escáner como PTKD.com analiza la compilación de tu app y devuelve hallazgos ordenados por gravedad y asociados a OWASP MASVS, incluidas debilidades de red y protecciones ausentes, para que veas dónde falta el pineado o falla la comunicación segura. Para dejar clara la frontera: PTKD no implementa el pineado ni configura tu servidor. Muestra, frente a los controles de la MASVS, qué protecciones faltan para que las añadas antes de publicar.
Qué debes recordar
- El pineado de certificados bloquea la interceptación casual en dispositivos normales, pero es eludible en un dispositivo con root, así que es una capa, no una garantía.
- La MASVS es el estándar de requisitos, el qué, y la MASTG es la guía de pruebas, el cómo; se usan juntas.
- El control aplicable es MASVS-NETWORK, y su verificación se apoya en las pruebas de la MASTG sobre tu propia app.
- Prueba solo tu app en un dispositivo aislado, valida en el servidor y mantén los secretos fuera del cliente.
- Implementa el pineado como defensa en profundidad y usa PTKD.com para detectar dónde faltan protecciones de red frente a la MASVS.
