Censurar datos sensibles

Funciones

• ⚠️ La primera línea deja claro que el censurado con expresiones regulares nunca es completo y enumera lo que no ve
• Ocho tipos enmascarados: móviles, documentos de identidad chinos, números de tarjeta, correos, claves de API, JWT, bloques de clave privada y direcciones IP
• Cinco preajustes: todo / contacto / identidad y tarjetas / secretos / red
• ⚠️ Los documentos exigen un dígito de control correcto y las tarjetas pasar Luhn — un falso positivo molesta más que un olvido
• ⚠️ Las claves solo se reconocen con un prefijo explícito (`sk_live_`, `AKIA`, `ghp_`, `AIza`…): una regla genérica destruiría también hashes y contenidos Base64, y eso es cambiar los datos del usuario
• Los correos conservan el dominio (`zh····@example.com`) para que sigas viendo de qué proveedor es
• Los bloques de clave privada se sustituyen por `[PRIVATE KEY REDACTED]` — taparlos con asteriscos parecería una fuga a medias
• El carácter de enmascarado se puede cambiar (en algunos contextos encaja mejor otro)
• Modo opcional «solo la lista»: muestra cada par original → censurado para comprobarlo antes de decidir si lo envías
• ⚠️ Ningún tramo lo reescriben dos reglas: los intervalos ya ocupados se controlan

Cómo se usa

1. Pega el texto que quieres censurar
2. Elige qué censurar (todo por defecto) y cambia el carácter de enmascarado si quieres
3. El resultado da el texto censurado y un recuento de lo que cambió
4. ¿Dudas? Cambia a «solo la lista» y mira primero qué cambiaría

Preguntas frecuentes

¿Basta con censurarlo para poder enviarlo?

No. Las expresiones regulares solo reconocen formas fijas, y «sensible» no depende de la forma: el nombre, la dirección, la empresa, el diagnóstico o el itinerario de una persona escritos en la prosa le pasan completamente inadvertidos. Tampoco conoce tus propios esquemas de numeración (`UID-9f3a2b`). Su papel aquí es el de una red de seguridad antes de enviar: atrapa las fugas más habituales, pero si enviarlo o no sigue siendo tu decisión.

¿Por qué un documento con el dígito de control mal no se toca?

Porque censurar cambia el contenido, y un falso positivo molesta más que un olvido: un olvido no se ve, mientras que un falso positivo está ahí en el resultado y hace pensar que la herramienta ha roto los datos. Por eso solo se tocan las coincidencias seguras: el documento necesita el dígito de control correcto y la tarjeta pasar Luhn. El precio es que un documento «con la forma correcta pero el dígito mal» no se procesa; una cadena así normalmente no es un documento.

¿Por qué no se reconocieron algunas claves?

Porque solo se reconocen las claves con un prefijo explícito (`sk_live_`, `AKIA`, `ghp_`, `xoxb_`, `AIza`…). Una regla genérica —«una tirada larga de letras y dígitos»— destruiría también hashes, contenidos Base64 e identificadores sin sentido, y eso es editar los datos del usuario en vez de censurarlos, dejándole algo inservible. Para una clave propia sin prefijo, tápala a mano.

¿Por qué el correo conserva el dominio?

Porque el dominio es muchas veces justo lo que se quiere ver: `zhangsan@company.com` y `zhangsan@gmail.com` se diferencian mucho cuando depuras, y «es una dirección de empresa» rara vez es sensible en un ticket. Así que se enmascara la parte local y se conserva el dominio. Si tampoco puedes mostrar el dominio, cambia el carácter de enmascarado y vuelve a procesarlo a mano.