Una de las nuevas características de HTML5 son los mensajes entre documentos. Esta función permite que las secuencias devuelvan mensajes en otras ventanas. La API correspondiente permite al usuario especificar el origen de la ventana de destino. No obstante, se debe prestar especial atención a la hora de especificar el origen de destino, dado que un origen de destino demasiado permisivo hará posible que un script malicioso pueda comunicarse con la ventana en cuestión de forma inapropiada, lo que permitiría la suplantación de identidad, el robo de datos, la retransmisión y otras formas de ataque.

Ejemplo 1: el siguiente ejemplo utiliza un carácter comodín para especificar mediante programación el origen de destino del mensaje que se va a enviar.

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

Utilizando el * como el valor del origen de destino, se indica que la secuencia envía un mensaje a una ventana independientemente de su origen.

De forma predeterminada, los exploradores no envían el encabezado de referencia con las solicitudes originadas desde HTTPS a vínculos HTTP sin cifrar. Sin embargo, cuando el destino de una solicitud también es HTTPS, se envía el encabezado independientemente del origen. Un desarrollador puede dejar información confidencial en las URL, las cuales se exponen a sitios de terceros mediante el encabezado de referencia. El encabezado Referrer-Policy se introduce para controlar el comportamiento del explorador en relación con el encabezado de referencia. La opción Unsafe-URL elimina todas las restricciones y envía el encabezado de referencia con cada solicitud.

Ejemplo: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la directiva de referencia segura predeterminada:

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

La directiva de seguridad de contenido (CSP) es un encabezado de seguridad declarativo que permite a los desarrolladores establecer los dominios en los que el sitio puede cargar contenido o con los que puede inicializar conexiones cuando se procesa en el explorador web. Esta directiva proporciona una capa de seguridad adicional contra vulnerabilidades críticas, como los ataques Cross-Site Scripting, el secuestro de clics (clickjacking), el acceso de origen cruzado y similares, por encima de la validación de entrada y la comprobación de listas de permitidos en el código.

El encabezado Content-Security-Policy-Report-Only brinda la capacidad para que los administradores y los autores de aplicaciones web supervisen las directivas de seguridad, en lugar de aplicarlas. Generalmente, este encabezado se utiliza mientras se desarrollan o se prueban directivas de seguridad para un sitio. Cuando se considera que una directiva es efectiva, es posible utilizar el encabezado Content-Security-Policy para aplicarla.

Ejemplo 1: El siguiente código establece una directiva de seguridad de contenido en el modo Report-Only:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

Se permite que las extensiones de teclado lean cada tecla que pulsa el usuario. Por lo general, los teclados de terceros se usan para facilitar la introducción de texto o para agregar emojis adicionales y pueden registrar lo que el usuario pulsa o incluso enviarlo a un servidor remoto para su procesamiento. Los teclados malintencionados también pueden distribuirse para actuar como un registrador de pulsaciones de teclas y leer todas las teclas pulsadas por el usuario para robar datos confidenciales como credenciales o números de tarjetas de crédito.

La extensión recibe los datos de la aplicación host en su controlador de vistas y no implementa SLComposeServiceViewController isContentValid para validar los datos que no son de confianza antes de usarlos.

Ejemplo 1: el siguiente controlador de vistas de extensión recibe datos de la aplicación host pero no implementa un método de devolución de llamada para validarlos:

    #import <MobileCoreServices/MobileCoreServices.h>

    @interface ShareViewController : SLComposeServiceViewController
        ...
    @end

    @interface ShareViewController ()
        ...
    @end

    @implementation ShareViewController

    - (void)didSelectPost {
        NSExtensionItem *item = self.extensionContext.inputItems.firstObject;
        NSItemProvider *itemProvider = item.attachments.firstObject;
        ...
        // Use the received items
        ...
        [self.extensionContext completeRequestReturningItems:@[] completionHandler:nil];
    }

    ...

    @end

Cuando una aplicación de terceros o webview usa una URL para comunicarse con su aplicación, la aplicación receptora debe verificar que el remitente coincida con la lista de aplicaciones permitidas que se espera que se comuniquen con esta. La aplicación receptora tiene la opción de verificar el origen de la URL de llamada mediante los métodos de delegación UIApplicationDelegate application:openURL:options: o UIApplicationDelegate application:openURL:sourceApplication:annotation:.

Ejemplo 1: la siguiente implementación del método de delegación UIApplicationDelegate application:openURL:options: no verifica el remitente de la llamada de IPC y simplemente procesa la URL de llamada:

    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options {
        NSString *theQuery = [[url query] stringByRemovingPercentEncoding:NSUTF8StringEncoding];
        NSArray *chunks = [theQuery componentsSeparatedByString:@"&"];
        for (NSString* chunk in chunks) {
            NSArray *keyval = [chunk componentsSeparatedByString:@"="]; NSString *key = [keyval objectAtIndex:0];
            NSString *value = [keyval objectAtIndex:1];
            // Do something with your key and value
        }
        return YES;
    }

Cuando una aplicación de terceros o webview usa una URL para comunicarse con su aplicación, la aplicación receptora debe validar la URL que efectúa la llamada antes de realizar más acciones. La aplicación receptora tiene la opción de verificar si desea abrir la URL de llamada mediante los métodos de delegación UIApplicationDelegate application:didFinishLaunchingWithOptions: o UIApplicationDelegate application:willFinishLaunchingWithOptions:.

Ejemplo 1: la siguiente implementación del método de delegación UIApplicationDelegate application:didFinishLaunchingWithOptions: no valida la URL de llamada y siempre procesa la URL que no es de confianza:

    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NS Dictionary *)launchOptions {
        return YES;
    }