Monitorowanie aplikacji internetowej za pomocą interfejsu API do raportowania

Używaj interfejsu API do raportowania do monitorowania naruszeń bezpieczeństwa, wycofanych wywołań interfejsu API i innych zdarzeń.

Maud Nalpas

Niektóre błędy występują tylko w środowisku produkcyjnym. Nie zobaczysz ich lokalnie ani podczas programowania, ponieważ prawdziwi użytkownicy, prawdziwe sieci i prawdziwe urządzenia zmieniają grę. Interfejs API do raportowania pomaga wykrywać niektóre z tych błędów, np. naruszenia bezpieczeństwa lub wywołania interfejsu API, które są wycofane lub wkrótce zostaną wycofane w całej witrynie, i przesyłać je do określonego przez Ciebie punktu końcowego.

Umożliwia deklarowanie, co chcesz monitorować za pomocą nagłówków HTTP, i jest obsługiwany przez przeglądarkę.

Skonfigurowanie interfejsu API do raportowania daje pewność, że gdy użytkownicy napotkają tego typu błędy, będziesz o tym wiedzieć i będziesz mieć możliwość ich naprawienia.

Z tego posta dowiesz się, co potrafi ten interfejs API i jak z niego korzystać. Zaczynajmy!

Przegląd

Diagram podsumowujący czynności opisane poniżej, od wygenerowania raportu do uzyskania do niego dostępu przez dewelopera
Jak są generowane i wysyłane raporty.

Załóżmy, że Twoja witryna site.example ma nagłówki Content-Security-Policy i Document-Policy. Nie wiesz, do czego służą te elementy? Nie szkodzi, nadal będziesz w stanie zrozumieć ten przykład.

Decydujesz się monitorować swoją witrynę, aby wiedzieć, kiedy te zasady są naruszane, ale także dlatego, że chcesz mieć oko na wycofane lub wkrótce wycofane interfejsy API, których może używać Twoja baza kodu.

Aby to zrobić, skonfiguruj nagłówek Reporting-Endpoints i zmapuj nazwy punktów końcowych za pomocą dyrektywy report-to w zasadach, w których jest to potrzebne.

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

Wystąpi nieprzewidziana sytuacja, w wyniku której zasady zostaną naruszone w przypadku niektórych użytkowników.

Przykłady naruszenia zasad

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js, wczytane przez index.html

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

Przeglądarka generuje raport o naruszeniu CSP, raport o naruszeniu zasad dotyczących dokumentu i raport o wycofaniu, które rejestrują te problemy.

Z niewielkim opóźnieniem (do minuty) przeglądarka wysyła raporty do punktu końcowego skonfigurowanego dla tego typu naruszenia. Raporty są wysyłane poza pasmem przez samą przeglądarkę (nie przez Twój serwer ani witrynę).

Punkty końcowe otrzymują te raporty.

Możesz teraz uzyskać dostęp do raportów w tych punktach końcowych i sprawdzić, co poszło nie tak. Możesz zacząć rozwiązywać problem, który ma wpływ na użytkowników.

Przykładowy raport

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",