Datenschutz und Filtern für Browser-Daten

Browser monitoring ist ein Beta-Feature von AppSignal Labs. Das Paket @appsignal/browser wird unter dem beta-Tag auf npm veröffentlicht, und seine Konfiguration und API können sich zwischen Beta-Releases noch ändern. Teilen Sie Ihr Feedback in unserer Discord-Community.

Front-end-Telemetrie liegt näher an personenbezogenen Daten als Back-end-Telemetrie. URLs tragen Tokens, Formulare tragen Kartennummern, und der Text auf einer Schaltfläche kann eine Bestellsumme sein. AppSignal für Browser ist standardmäßig zurückhaltend, und jede weitere Entscheidung konfigurieren Sie selbst.

Was standardmäßig geschützt ist

Ohne jede Konfiguration:

Die meisten vom SDK erzeugten URL-Felder lassen Query-Parameter standardmäßig weg. Das betrifft Fehlerseiten-URLs, web-vital-Seiten-URLs, Navigations-Breadcrumbs und fetch/XMLHttpRequest-Breadcrumbs. Der anfängliche Netzwerk-Breadcrumb beim Laden des Dokuments ist eine Ausnahme, die weiter unten erklärt wird.
Das SDK liest keine Request- oder Response-Bodies von Netzwerkaufrufen. Prüfen Sie Daten, die Ihr eigener Code in Fehler, Konsolenausgaben, Tags oder manuelle Breadcrumbs einfügt.
Es werden keine Cookies gelesen oder geschrieben. Das SDK speichert appsignal_*-Werte in localStorage und sessionStorage. Dazu gehören zufällige IDs für Session, Tab und Besucher, die Aktivitätszeit und die Tags, die Sie gesetzt haben. Die Besucher-ID ist ein zufälliger Wert ohne persönlichen Inhalt. Die Besucher-ID bleibt zwischen Besuchen bestehen. Behandeln Sie sie als Identifikator in Ihrer Datenschutzerklärung.
Konsolen-Warnungen und -Fehler werden abgeschnitten, nach den ersten 200 Zeichen. Das SDK erfasst kein console.log.
Es wird nichts gesendet, wenn active false ist. Das SDK ändert nichts auf der Seite, startet keine Timer und stellt keine Requests.

URLs und Query-Parameter

privacy.queryParamsAllowlist listet die Query-Parameter auf, die in den folgenden URL-Feldern erhalten bleiben. Andere Query-Parameter werden aus diesen Feldern entfernt. Sie können * verwenden, um mehrere Namen auf einmal zu treffen, utm_* behält also jeden UTM-Parameter. Die Standardliste ist leer, wodurch alle entfernt werden. Das gilt für fetch/XMLHttpRequest- und Navigations-Breadcrumbs. Es gilt außerdem für automatisch gemeldete Request-Fehler, Fehlerseiten-URLs, Referrer und web-vital-Seiten-URLs.

init({
  key: "<YOUR_FRONTEND_API_KEY>",
  privacy: {
    queryParamsAllowlist: ["utm_*", "page"],
  },
});

Mit dieser Einstellung:

URL	Bereinigtes URL-Feld
`https://example.com/search?q=alice@corp.com&page=2`	`https://example.com/search?page=2`
`https://example.com/dashboard?utm_source=email&token=abc`	`https://example.com/dashboard?utm_source=email`
`https://example.com/callback#access_token=ey123&token_type=bearer`	`https://example.com/callback`
`https://example.com/checkout#/payment`	unverändert

Die letzten beiden Zeilen sind das entscheidende Paar. Beide URLs haben etwas nach einem #, und sie werden absichtlich unterschiedlich behandelt. Die dritte URL hat reine query-artige Daten nach dem #, daher entfernt das SDK deren Token aus diesen bereinigten Feldern. Die vierte URL ist eine Hash-Route, die das SDK beibehält. Das gilt auch für jeden Query-Text innerhalb einer Hash-Route, etwa #/payment?token=abc. Halten Sie Geheimnisse aus Hash-Routen heraus. Einfache Anker wie #pricing bleiben ebenfalls erhalten.

Der anfängliche Netzwerk-Breadcrumb beim Laden des Dokuments verwendet derzeit die vollständige Landing-URL, selbst wenn queryParamsAllowlist leer ist. networkBlocklist filtert ihn nicht. Wenn Landing-URLs Geheimnisse enthalten können, verwerfen Sie diesen Breadcrumb mit beforeBreadcrumb:

import { init } from "@appsignal/browser";

init({
  key: "<YOUR_FRONTEND_API_KEY>",
  endpoint: "https://appsignal-endpoint.net",
  beforeBreadcrumb: (breadcrumb) =>
    breadcrumb.category === "network" && breadcrumb.data?.initiator === "document"
      ? null
      : breadcrumb,
});

Netzwerk-Requests ausschließen

privacy.networkBlocklist listet fetch- und XMLHttpRequest-Aufrufe auf, die keinen Breadcrumb hinterlassen sollen und die auch nie als fehlgeschlagene Requests gemeldet werden. Der Request findet wie gewohnt statt. Nur seine Aufzeichnung wird übersprungen. Muster werden gegen den Host und den Pfad der URL abgeglichen. Ein einzelnes * trifft einen Teil des Pfads, ** trifft beliebig viele Teile.

init({
  key: "<YOUR_FRONTEND_API_KEY>",
  privacy: {
    networkBlocklist: [
      "api.stripe.com/**",      // every request to that host
      "*/auth/token",           // that path on any host
      "example.com/users/*/card" // any single ID in that position
    ],
  },
});

Seitenelemente maskieren und blockieren

Zwei Optionen steuern, was aufgezeichnet wird, wenn ein Nutzer etwas auswählt. Beide Optionen nehmen CSS-Selektoren entgegen. Die Auswahl eines Containers deckt auch dessen Nachfahren ab. privacy.dom.maskText ersetzt Text aus einem passenden Element durch [masked]. Der Breadcrumb wird weiterhin aufgezeichnet, Sie behalten also die Information, dass jemand das Element ausgewählt hat:

maskText: [".pay-button"]

click  button "Pay $42.00"   →   click  button "[masked]"

Ein data-breadcrumb-Label hat Vorrang vor der Textmaskierung. Legen Sie keine sensiblen Werte in dieses Attribut. privacy.dom.blockElement zeichnet überhaupt nichts auf. Verwenden Sie es für Kartenformulare, Ausweisnummern und alles, was niemals auftauchen soll:

blockElement: ["#card-form"]

click  input#cvc   →   (nothing recorded)

Diese beiden Optionen betreffen nur, was aufgezeichnet wird, wenn ein Nutzer etwas auswählt. Sie berühren keine Fehlermeldungen, Netzwerk-URLs oder Konsolen-Warnungen und -Fehler. Verwenden Sie dafür queryParamsAllowlist, networkBlocklist und die beiden Funktionen im folgenden Abschnitt.

Fehler und Breadcrumbs filtern

Zwei Hooks erlauben es Ihnen, Fehler vor der Meldung und Breadcrumbs zu filtern, bevor sie in den Buffer gelangen. Keine von beiden darf async sein. beforeError läuft für Fehler, die sampling und das globale Rate-Limit passieren. Geben Sie null zurück, um einen Fehler zu verwerfen, oder ändern Sie seine Felder, um sensiblen Text zu entfernen:

import { init } from "@appsignal/browser";

const EMAIL_PATTERN = /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi;

init({
  key: "<YOUR_FRONTEND_API_KEY>",
  beforeError: (event) => {
    // Drop known noise
    if (/ResizeObserver/.test(event.message)) return null;

    // Redact email addresses from the message and the stack
    event.message = event.message.replace(EMAIL_PATTERN, "[redacted]");
    event.stack = event.stack?.replace(EMAIL_PATTERN, "[redacted]");
    return event;
  },
});

null zurückzugeben sendet keinen Fehler und fügt keinen Fehler-Breadcrumb hinzu. Das globale Rate-Limit wird zuerst geprüft, verworfene Fehler zählen also trotzdem dazu. Ein fehlgeschlagener Request kommt hier als HTTPError oder TimeoutError an. Seine Felder url, method, status und duration_ms liegen unter context.request. Wenn Sie die URL dort redigieren, redigieren Sie sie auch in der Fehlermeldung, die die Request-URL enthält. beforeBreadcrumb läuft einmal für jeden Breadcrumb, während er aufgezeichnet wird. Geben Sie null zurück, um ihn zu verwerfen, oder ändern Sie message und data:

init({
  key: "<YOUR_FRONTEND_API_KEY>",
  beforeBreadcrumb: (breadcrumb) => {
    if (breadcrumb.category === "console") return null;
    return breadcrumb;
  },
});

beforeError kann keine Breadcrumbs sehen, weil sie dem Fehler erst angehängt werden, nachdem diese Funktion ihn freigegeben hat. Verwenden Sie stattdessen beforeBreadcrumb, um Breadcrumb-Inhalte zu bereinigen.

Keine der beiden Funktionen darf async sein. Wenn beforeError ein Promise zurückgibt, loggt AppSignal einen console.error und verwirft den Fehler. Erledigen Sie langsame Arbeit, bevor Sie captureError aufrufen, nicht innerhalb dieser Funktionen.

Es wird nichts erfasst, bis init() läuft, zuerst um Zustimmung zu bitten ist also eine Frage davon, es nicht aufzurufen, bevor Sie sie haben:

import { init, destroy } from "@appsignal/browser";

if (consent.granted("analytics")) {
  init({ key: "<YOUR_FRONTEND_API_KEY>", endpoint: "https://appsignal-endpoint.net" });
}

consent.on("revoked", () => destroy());

destroy() stoppt die Erfassung sofort und sendet, was es bereits gesammelt hatte. Es betrifft nur die Seite, auf der der Nutzer ist. Speichern Sie seine Entscheidung selbst und prüfen Sie sie, bevor Sie init() aufrufen, sonst beginnt die nächste Seite, die er öffnet, wieder mit der Erfassung.

Was Sie Ihren Nutzern sagen können

Ein gemeldeter Fehler kann bis zu 25 aktuelle Breadcrumbs enthalten. Je nachdem, was zuvor geschah, können diese Folgendes beschreiben:

Die Seiten, die sie geöffnet haben.
Was sie ausgewählt haben und wo auf dem Bildschirm sie es ausgewählt haben. Klick-Labels können sichtbaren Text enthalten, maskieren Sie also sensible Elemente.
Die Requests, die die Seite gestellt hat, und ob jeder davon erfolgreich war.
Warnungen und Fehler, die die Seite in der Konsole protokolliert hat.
Lange Tasks.

Der Fehler enthält außerdem alle Tags, die Sie gesetzt haben. Web-vital-Batches enthalten Metrikwerte und Besuchskontext, aber standardmäßig nicht diese Breadcrumb-Spur. Die Breadcrumbs-Seite enthält die vollständige Liste. Jeder web-vitals-Batch trägt außerdem Besuchskontext. Dazu gehören zufällige IDs für Session, Tab und Besucher, die Seiten-URL und ihr Referrer. Dazu gehören außerdem der User Agent, die Größe von Bildschirm und Fenster, die Sprache und die Zeitzone. Wo der Browser sie bereitstellt, trägt er auch den Verbindungstyp und wie viel Speicher das Gerät hat. Das SDK liest keine Formularfeldwerte, Netzwerk-Bodies oder Cookies direkt. Das SDK erzeugt eine zufällige Besucher-ID. Sie bleibt zwischen Besuchen auf dem Gerät. Ihre eigenen Fehlermeldungen, Tags und Breadcrumbs können personenbezogene Details enthalten. Prüfen Sie diese, bevor Sie Daten an AppSignal senden.

SDKs & Telemetrie

Sprach-SDKs

Telemetrie-Tools

Datenschutz und Filtern für Browser-Daten

Was standardmäßig geschützt ist

URLs und Query-Parameter

Netzwerk-Requests ausschließen

Seitenelemente maskieren und blockieren

Was Sie Ihren Nutzern sagen können

​Was standardmäßig geschützt ist

​URLs und Query-Parameter

​Netzwerk-Requests ausschließen

​Seitenelemente maskieren und blockieren

​Fehler und Breadcrumbs filtern

​Zustimmung zum Tracking

​Was Sie Ihren Nutzern sagen können

Was standardmäßig geschützt ist

URLs und Query-Parameter

Netzwerk-Requests ausschließen

Seitenelemente maskieren und blockieren

Fehler und Breadcrumbs filtern

Zustimmung zum Tracking

Was Sie Ihren Nutzern sagen können