La mayoría de las apps para iPhone gestionan los datos del usuario mal. Si fallas en seguridad, perjudicas a los usuarios, destruyes tu reputación y a veces incumples la ley. Aquí tienes la base de seguridad que todo desarrollador iOS debe cubrir — desde el almacenamiento de datos y la autenticación hasta la seguridad de red y el envío de builds limpios para producción.

Almacenamiento de datos: donde fallan la mayoría de apps

Usa Keychain para datos sensibles

UserDefaults no es seguro. Se guarda como un archivo plist en texto plano. Cualquiera con acceso al dispositivo o a una copia de seguridad puede leerlo.

Las credenciales, los tokens y cualquier cosa sensible van en el Keychain. Punto. Si tu app guarda un token de autenticación en UserDefaults, arréglalo hoy mismo.

• Usa kSecAttrAccessibleWhenUnlockedThisDeviceOnly para tokens que no deberían sobrevivir a una restauración del dispositivo.
• Nunca guardes contraseñas. Guarda tokens. Caduca los tokens. Refréscalos.

Cifra los archivos sensibles

Si tu app escribe datos sensibles en disco — documentos, respuestas en caché, datos de usuario — usa iOS Data Protection. Activa NSFileProtectionComplete en archivos que solo deberían ser accesibles cuando el dispositivo está desbloqueado.

Core Data y SwiftData también soportan Data Protection. Actívalo en tus entitlements, no solo en código.

Seguridad de red

HTTPS en todas partes

App Transport Security (ATS) impone HTTPS por defecto en iOS. No lo desactives. No añadas excepciones NSAllowsArbitraryLoads a menos que tengas una razón documentada.

TLS 1.2 como mínimo. TLS 1.3 cuando tu servidor lo soporte.

Certificate pinning para flujos sensibles

Para apps que manejan datos financieros, datos de salud o autenticación — fija tus certificados. Esto previene ataques man-in-the-middle incluso cuando el dispositivo confía en una CA fraudulenta.

Usa URLSession con un URLSessionDelegate personalizado para implementar el pinning. Librerías como TrustKit hacen el trabajo pesado si no quieres mantenerlo manualmente.

No todas las apps necesitan pinning. Salud, fintech y cualquier cosa con datos de usuario sensibles, sí.

Autenticación

Usa OAuth 2.0 con PKCE

No te inventes tu propio sistema de autenticación. Usa OAuth 2.0 con PKCE (Proof Key for Code Exchange) para autenticar usuarios. Es el estándar actual y elimina el ataque de interceptación del código de autorización.

El ASWebAuthenticationSession de Apple gestiona el flujo basado en navegador correctamente. Úsalo.

Autenticación biométrica

Face ID y Touch ID se gestionan a través del framework Local Authentication. Úsalos para desbloqueo local de la app, no como sustituto de una sesión del lado del servidor. La biometría confirma al dueño del dispositivo — no al dueño de la cuenta.

Sign in with Apple

Si tu app soporta login de terceros (Google, Facebook, etc.), Apple exige Sign in with Apple como opción. Además es genuinamente bueno para los usuarios — sin recolección de emails, con relé de privacidad incorporado. Impleméntalo bien, no como un añadido a última hora.

Claves de API y secretos

No pongas secretos en el bundle de tu app. Nunca.

• Las claves de API en el código fuente se extraen del binario. Es trivial. No lo hagas.
• Los secretos pertenecen a tu backend. Tu app se autentica contra tu backend; tu backend llama a la API de terceros.
• Para claves que deben vivir en el dispositivo (SDKs de analítica, etc.), usa ofuscación — no es seguridad, pero sube el listón.

Revisa tu código en busca de claves de API hardcodeadas antes de cada release. Usa git-secrets o herramientas similares para detectarlas en CI.

Privacidad del usuario

Pide solo lo que necesitas

Cada solicitud de permiso — cámara, ubicación, contactos — debe tener un purpose string claro. Apple los revisa. Los usuarios los leen. Los textos vagos son rechazados; los permisos agresivos hacen que borren tu app.

Pide los permisos en el momento de uso, no al lanzar la app. Pedir ubicación al primer arranque, antes de mostrar para qué la necesitas, garantiza un "denegar".

Etiquetas de privacidad de la App Store

Tu ficha en la App Store requiere etiquetas de privacidad precisas. Mentir en ellas hace que retiren tu app. Audita qué datos recogen tus SDKs de terceros — los SDKs de analítica y publicidad suelen recoger más de lo que crees.

Riesgos a nivel de código

Validación de entrada

Valida todo lo que viene del usuario o de la red. No asumas que el servidor lo va a pillar. No asumas que las restricciones de UI son suficientes. Valida en la capa del modelo.

Detección de jailbreak

Para apps de alta seguridad (banca, salud), añade detección de jailbreak. No es infalible, pero sube el coste del ataque. Comprueba rutas comunes de jailbreak, Cydia y violaciones de sandbox.

Desactiva el debug logging en producciónLos logs verbosos en builds de release son un riesgo de seguridad. Usa compilación condicional para eliminar la salida de debug: #if DEBUG ... #endif. Nunca registres tokens, contraseñas ni PII — ni siquiera en builds de debug.

Seguridad en build y despliegue

• Activa Hardened Runtime para apps de Mac Catalyst.
• Firma todos los builds. Los builds sin firmar pueden ser manipulados.
• Usa la información de cumplimiento de exportación de App Store Connect con precisión. La mayoría de apps califican para la exención estándar de cifrado.
• Rota credenciales cada vez que un miembro del equipo se va.

Por dónde empezar

Si estás auditando una app existente, prioriza en este orden:

1. Almacenamiento de credenciales — mueve cualquier dato sensible de UserDefaults a Keychain.
2. Seguridad de red — verifica HTTPS en todas partes, sin excepciones de ATS.
3. Claves de API — encuentra y elimina cualquier cosa hardcodeada.
4. Etiquetas de privacidad — audita lo que tus SDKs realmente recogen.
5. Validación de entrada — añade validación a nivel de modelo para los campos visibles al usuario.

No intentes arreglarlo todo a la vez. Arregla primero los problemas críticos, luego trabaja sistemáticamente el resto.

Cuándo pedir ayuda

Las auditorías de seguridad por parte de especialistas merecen la pena antes de grandes lanzamientos, rondas de financiación o al entrar en sectores regulados. Una buena auditoría saca a la luz problemas que tu equipo no ve por estar demasiado cerca del código.

En Applefy, integramos la seguridad desde el principio — no como un parche posterior. Si estás heredando una base de código y quieres una evaluación honesta, habla con nosotros.

Preguntas frecuentes

¿Cuál es el error de seguridad más común en iOS?

Guardar credenciales en UserDefaults en lugar de Keychain. Es el problema que más vemos en revisiones de código y el más fácil de arreglar.

¿Toda app necesita certificate pinning?

No. El certificate pinning tiene sentido para apps que manejan datos financieros, registros sanitarios o tokens de autenticación. Para la mayoría de apps de consumo, HTTPS estándar es suficiente.

¿Cómo compruebo si mi app tiene claves de API hardcodeadas?

Busca patrones comunes en tu código: cadenas que terminan en _key, _secret, _token. Ejecuta git-secrets o trufflehog sobre tu repo. Revisa la configuración de tus SDKs de terceros.

¿Qué pasa si mi app falla la revisión de etiquetas de privacidad de Apple?

Apple rechazará el build y te pedirá que corrijas las etiquetas antes de reenviar. La inexactitud repetida puede llevar a que retiren tu app de la App Store.

¿Necesito implementar Sign in with Apple?

Sí, si tu app soporta cualquier método de login de terceros (Google, Facebook, Twitter, etc.). Apple exige Sign in with Apple como opción en esos casos.