Scripts de primeira parte são trechos de JavaScript servidos diretamente do próprio domínio de um site. Costumam estar sob o controle da equipe de desenvolvimento do site, o que os torna mais simples de auditar e gerenciar. Como o próprio site os hospeda, os administradores podem usar revisões internas de código, controle de versão e cabeçalhos de segurança rígidos (como a Content Security Policy) para reduzir vulnerabilidades. No entanto, mesmo scripts de primeira parte podem conter falhas de segurança por causa de cadeias de dependências, normalmente compiladas por um gerenciador de pacotes. Em um contexto de segurança client-side, avaliar e atualizar corretamente o código de primeira parte é essencial para se defender de ataques como cross-site scripting (XSS) e exfiltração de dados.
Um script first-party (de origem própria) é JavaScript servido a partir do domínio do próprio site e, em princípio, controlado pela própria equipe desse site. Como a organização hospeda e distribui o código, ela pode aplicar toda a gama de controles internos: revisão de código-fonte, controle de versão, um pipeline de build e cabeçalhos de segurança como a Content Security Policy. Os scripts first-party cuidam do comportamento central de um site, formulários, interatividade e lógica da aplicação, e costumam ser o código em que a equipe mais confia. Na prática, porém, a maioria dos bundles first-party é montada a partir de pacotes de código aberto trazidos por um gerenciador de pacotes, então o código que de fato é distribuído inclui muitas dependências que a equipe não escreveu.
Ser confiável não significa ser seguro. Um script first-party herda toda vulnerabilidade em sua árvore de dependências, então um pacote npm comprometido ou malicioso se torna código first-party no momento do build, um caminho de cadeia de suprimentos de software por trás de vários incidentes reais. O código first-party também é um sink frequente de XSS: se ele insere entrada não confiável no DOM ou avalia strings dinâmicas, entrega aos atacantes a execução sob a própria origem do site. E em uma página de pagamento o navegador não consegue distinguir first-party de third-party, ambos são executados com o mesmo acesso aos campos de formulário e aos cookies, então uma falha no código first-party expõe exatamente os dados que um atacante quer.
Verifique as dependências com lockfiles, auditorias e versões fixadas, revise e codifique qualquer código que escreva no DOM e use uma CSP estrita para que um script injetado tenha alcance limitado. A Subresource Integrity protege o código que você carrega de um CDN. Para conformidade, o PCI DSS 6.4.3 exige um inventário e a autorização de cada script em páginas de pagamento, incluindo os first-party, e o 11.6.1 exige detectar alterações não autorizadas neles. A cside monitora os scripts que realmente são executados no navegador e analisa seu comportamento, de modo que um bundle first-party que passa a ler campos de cartão ou a contatar um domínio desconhecido, seja por uma dependência envenenada ou por uma injeção, é sinalizado, pode ser bloqueado em tempo real e é registrado para fins forenses.
Em geral sim, porque você controla a origem, a hospedagem e o processo de lançamento, mas não automaticamente. Os bundles first-party costumam incluir dependências third-party trazidas de gerenciadores de pacotes, então herdam risco de cadeia de suprimentos. A vantagem é o controle e a auditabilidade, não uma imunidade inerente a comprometimentos ou vulnerabilidades.
Não. Os requisitos 6.4.3 e 11.6.1 se aplicam a todo script que é executado em uma página de pagamento, independentemente da origem. Você precisa inventariar e justificar cada um, incluindo os first-party, e ser capaz de detectar alterações não autorizadas neles, porque o navegador dá a todos o mesmo acesso a campos sensíveis.
We answer client-side security questions every day. Bring yours.