Um dos novos recursos do HTML5 é enviar mensagens entre documentos. O recurso permite que os scripts publiquem mensagens em outras janelas. A API correspondente permite ao usuário especificar a origem da janela de destino. No entanto, deve-se ter cautela ao especificar a origem pretendida porque caso ela seja excessivamente permissiva, permitirá que um script malicioso se comunique com a janela da vítima de forma inadequada, levando à falsificação, ao roubo de dados, a ataques de retransmissão e outros.

Exemplo 1: O exemplo a seguir usa um curinga para especificar programaticamente a origem pretendida da mensagem a ser enviada.

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

Usar o * como o valor da origem pretendida indica que o script está enviando uma mensagem a uma janela, independentemente da respectiva origem.

Os navegadores não enviam o cabeçalho do referenciador por padrão com solicitações originadas de HTTPS para links HTTP não criptografados. No entanto, quando um destino de solicitação também é HTTPS, o cabeçalho é enviado independentemente da origem. Um desenvolvedor pode deixar informações confidenciais em URLs, que são expostas a sites de terceiros por meio do cabeçalho do referenciador. O cabeçalho Referrer-Policy é introduzido para controlar o comportamento do navegador em relação ao cabeçalho do referenciador. A opção Unsafe-URL remove todas as restrições e envia o cabeçalho do referenciador com cada solicitação.

Exemplo: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a política de referenciador segura padrão:

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

A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativa que permite aos desenvolvedores ditar de quais domínios o local tem permissão para carregar conteúdo ou iniciar conexões durante a renderização no navegador da Web. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código.

O cabeçalho Content-Security-Policy-Report-Only fornece a autores e administradores de aplicativos Web a capacidade de monitorar políticas de segurança, em vez de impô-las. Esse cabeçalho geralmente é usado ao serem experimentadas e/ou desenvolvidas políticas de segurança para um site. Quando uma política é considerada efetiva, você pode impô-la usando o campo de cabeçalho Content-Security-Policy.

Exemplo 1: O seguinte código define uma Política de Segurança de Conteúdo no 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>

As extensões de teclado têm permissão para ler todas as teclas que um usuário pressiona. Os teclados de terceiros são normalmente usados para facilitar a entrada de texto ou para adicionar emojis adicionais, e eles podem registrar em log o que o usuário insere ou até mesmo enviar esses logs para um servidor remoto para processamento. Os teclados mal-intencionados também podem ser distribuídos para atuar como um keylogger e ler todas as teclas pressionadas pelo usuário, a fim de roubar dados confidenciais, como credenciais ou números de cartão de crédito.

A extensão recebe dados do aplicativo host no controlador de exibição e não pode implementar SLComposeServiceViewController isContentValid para validar os dados não confiáveis recebidos antes de usá-los.

Exemplo 1: O seguinte controlador de exibição da extensão recebe dados do aplicativo host, mas não pode implementar um método de chamada para validá-lo:

    #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

Quando um aplicativo ou webview de terceiros usa uma URL para se comunicar com seu aplicativo, o aplicativo receptor deve confrontar o remetente com uma lista de permissões com aplicativos que são esperados para se comunicar com ele. O aplicativo receptor tem a opção de verificar a origem da URL de chamada usando os métodos delegados UIApplicationDelegate application:openURL:options: ou UIApplicationDelegate application:openURL:sourceApplication:annotation:.

Exemplo 1: A seguinte implementação do método delegado UIApplicationDelegate application:openURL:options: falha ao verificar o remetente da chamada de IPC e processa apenas a URL de chamada:

    - (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;
    }

Quando um aplicativo ou webview de terceiros usa uma URL para se comunicar com seu aplicativo, o aplicativo receptor deve validar a URL de chamada antes de continuar com outras ações. O aplicativo receptor tem a opção de verificar se ele deseja abrir a URL de chamada usando os métodos delegados UIApplicationDelegate application:didFinishLaunchingWithOptions: ou UIApplicationDelegate application:willFinishLaunchingWithOptions:.

Exemplo 1: A seguinte implementação do método delegado UIApplicationDelegate application:didFinishLaunchingWithOptions: falha ao validar a URL de chamada e sempre processa a URL não confiável:

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