Vernetzte Dienste

Planen Sie zuverlässige APIs und Integrationen mit klaren Verträgen, Zugriffsregeln und Fehlerbehandlung.

52 Artikel · Zuletzt aktualisierter Artikel

Die Suche erfasst alle Artikel dieses Themas, einschließlich Archiv und Artikeltext.

Verstehen Sie das Thema.

Ein praktischer Leitfaden zu diesem Thema.

Eine verbundene Funktion hängt von Identitäten, Schnittstellenverträgen, Lieferanten und Fehlermodi ab. Diese Kategorie verbindet API-Design, Sicherheit, Kontinuität und die Qualität des Service, den Benutzer erhalten.

Was ist zu prüfen?
  • Identifizieren Sie die für jeden Prozessablauf wesentlichen Aufrufe und deren Verantwortliche.
  • Planen Sie Fristen, Fehler, sichere Wiederholungsversuche und sichtbare Beeinträchtigungen.
  • Üben Sie Ausfälle, Wiederherstellung und Reaktion auf Vorfälle.
  • Vergleichen Sie die tatsächlichen Antworten mit dem dokumentierten Vertrag, bevor Sie eine Schnittstelle ändern.
  • Testen Sie die Berechtigungen für jedes GraphQL-Objekt und -Feld und binden Sie anschließend Verschachtelungen, Listen und Aliase zu den tatsächlichen Kosten.
  • Wandeln Sie eine empfangene Benachrichtigung in einen eindeutigen, nachvollziehbaren und nach einem Fehler wiederherstellbaren Geschäftseffekt um.
  • Gemeinsame, private und Anwendungscaches trennen, Schlüssel, Revalidierung und Invalidierung nach Änderungen der Zugriffsrechte prüfen.
  • URL-Importe können unbeabsichtigt interne Ressourcen erreichbar machen.
  • Begrenzungen beeinflussen Kapazität, Wiederholungen und Kundentrennung.
  • Reihenfolge, Token, Berechtigungen und Wiederaufnahme bei veränderlichen Sammlungen festlegen.
  • Empfangene Dateien müssen vor Veröffentlichung oder Verarbeitung geprüft werden.
  • Ein gemeinsamer Cache muss öffentliche und persönliche Antworten trennen.
  • Eine angenommene Anfrage beweist keine abgeschlossene Arbeit.
  • Erzeugte, empfangene und nutzbare Ereignisse trennen, statt Stille als Vorfallsfreiheit zu deuten.
  • Einen Nachrichtenvertrag für iframe oder Popup festlegen, der unerwartete Absender und Daten abweist.
  • Pfade, Links und entpackte Daten vor der Freigabe der Dateien prüfen.
  • Erneuerung bis zu Endpunkten und Clients verfolgen, bevor der Wechsel abgeschlossen wird.
Hilfreiche Fragen.
  • Was passiert, wenn ein Provider nicht mehr antwortet?
  • Kann ein Wiederholungsversuch eine Aktion wiederholen?
  • Welche Nachweise belegen die erfolgreiche Wiederherstellung?
  • Welche bestehenden Clients wären von einer neuen Version betroffen?
  • Kann ein Resolver ein privates Feld zurückgeben, nachdem dessen übergeordneter Resolver die Berechtigung erteilt hat?
  • Welche Bytes sind signiert?
  • Bedeutet „Kein Cache“, dass nichts gespeichert wird?
  • Genügt die Prüfung der ersten URL?
  • Beweist 429, dass ein früherer Schreibvorgang nicht ausgeführt wurde?
  • Bedeutet eine leere Seite das Ende?
  • Beweist eine erlaubte Endung die Sicherheit?
  • Verhindert ein Cookie gemeinsames Caching?
  • Beweist 202 einen späteren Abschluss?
  • Beweisen drei empfangene Zeilen drei gespeicherte Ereignisse?
  • Genügt die Prüfung von event.origin?
  • Garantiert ein kleines Archiv oder ein Filter Sicherheit?
  • Genügt erfolgreiche ACME-Erneuerung?

Beispiel einer Entscheidung.

Situation.
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse. Zwei Lesezugriffe sind schnell, doch einer zeigt nach einer Änderung der Quelle noch die alte Verfügbarkeit.
Prüfen.
Wert, Version, Leseort und Zeit seit der Änderung vergleichen. Invalidierung, Ablauf und Zugriff auf die Quelle gemäß Systemvertrag testen.
Handeln.
Zulässige Veralterung je Anwendung definieren und Abweichungen überwachen. Niedrigere Latenz belegt keine konsistenten Auslieferungsdaten.

API-Cache: Aktualität, Trennung und Konsistenz steuern

HTTP-Caching: Personalisierte Antworten schützen

IETF — RFC 9111, HTTP Caching

Empfänger und Berechtigungen prüfen

Ein signiertes Token autorisiert eine Objektoperation nicht automatisch. Aussteller, Empfänger, Ablaufdatum und kontoübergreifenden Zugriff prüfen; erwartete Ablehnungen neben erfolgreichen Fällen hinzufügen.

Wird ein für eine andere API oder Rolle gültiges Token tatsächlich abgelehnt?

Erkunden Sie die Methoden.

Daten lesen und entscheiden

API-Wiederholungen: das gesamte Zeitbudget zählen

Vier Versuche enthalten drei Wiederholungen.

Versuche insgesamt
41 + 3
Wartezeiten insgesamt (ms)
700100 + 200 + 400
Modellbudget (ms)
17004 × 250 + 700

Fiktiver Lehrfall: Die Zahlen beschreiben weder CIE noch Kunden.

Ein Wiederholungsbudget ausprobieren

n × T + W × (2^(n−1) − 1)

Fragen zur Vorbereitung Ihrer Entscheidungen

Antworten und praktische Prüfpunkte finden Sie in den Analysen dieser Rubrik.

Im Archiv weiterlesen

Weitere Analysen zu diesem Thema außerhalb der aktuellen Artikelliste.

Referenzen: Daten, Nutzung und Grenzen

Dokumentation geprüft am .

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Threat intelligence: content, exchange and sharingThree distinct functions. STIX 2.1 · Describe. TAXII 2.1 · Exchange. TLP 2.0 · Share. None establishes truth alone. Objects and relationships. Collections and protocol. Permitted recipients. Local validation: origin, period, relevance and permissions.Threat intelligence: content, exchange and sharingThree distinct functionsNone establishes truth aloneSTIX 2.1 · DescribeObjects and relationshipsTAXII 2.1 · ExchangeCollections and protocolTLP 2.0 · SharePermitted recipientsLocal validation: origin, period, relevance and permissions
Threat intelligence: content, exchange and sharing
Referenzen: Daten, Nutzung und Grenzen
Quelle und ZweckGeprüfte Daten oder RichtwertePraktische NutzungZu beachtende Grenze
MITRE · Common Weakness Enumeration

Name classes of software and hardware weakness.

 A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests.

Methode vertiefen →

 A keyword in a report alone does not establish the correct CWE classification.
OASIS · STIX 2.1

Describe threat intelligence through structured objects and relationships.

 STIX 2.1 is an OASIS Standard dated 10 June 2021. It defines objects, properties and JSON serialisation. Keep identifiers, dates, provenance and relationships. Check that the recipient interprets the same object type and validity period.

Methode vertiefen →

 A syntactically valid object can still be stale, misattributed or weakly supported.
OASIS · TAXII 2.1

Exchange threat intelligence through an application protocol.

 TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed.

Methode vertiefen →

 TAXII transports data; it replaces neither the content model nor assessment of reliability.

Identität: Faktoren, Sitzungen und Wiederherstellung

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Identity APIs: separate authentication and authorisation

A valid token identifies a session or identity under its protocol. It does not automatically grant access to every business object. Recovery and revocation must be checked on the consuming backend.

  • Check applicable issuer, audience, expiry and permissions.
  • Replay access to an unauthorised object and a revoked session.
  • Record useful decisions without logging authentication secrets.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, HTTP-Cache und gleichzeitige Änderungen

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Specify conflicts in the API contract

The contract should explain which validator accompanies a representation and how clients handle refusals.

  • State whether PUT requires a conditional field and when 428 is issued.
  • Document strong If-Match, 412 and the conflict-resolution journey.
  • Support HEAD and 304 without content and test SDK behaviour.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After: Wartezeit, Budget und Wiederholung

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Specify permission to repeat before retry timing

Retry-After describes waiting. The contract must also define replayable operations, keys, versions and unknown-result states.

  • State whether the field is seconds or a date and how clients handle absent or invalid values.
  • Name the retry controller and global budget to prevent overlapping attempts.
  • Retain parameters, context and the idempotency window without generalising Stripe to every API.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

CISA-KEV-Katalog durchsuchen

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

Katalog und Methode ansehen →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

Erweiterungen: Berechtigungen und Zugriff

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Syslog-Codes und Erfassungsnachweise

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Normalisation must preserve event meaning

In a distributed API, a PRI integer combines two codes. An opaque conversion may lose the message family or reverse severity. Test collection with identified events before inferring operational reliability.

  • Keep facility, severity and raw value in separate fields.
  • Distinguish source time, reception time and search availability.
  • Expose rejected events, truncation, loss and conversion rules.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

API-Fehler: Typen, Status und Nachweise

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Include errors in contract tests

A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.

  • Replay existing clients against representative refusals.
  • Check tolerance of unknown extensions and localised text.
  • Document migration of a problem identity and actually observed use.

Explore problem types and eight fictional responses →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

GraphQL: Fehler, Listen und Teildaten

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

GraphQL API: contract, access and reading experience

Extend API checks with partial-response acceptance cases, field-access tests and a resource budget specific to the service.

  • Compare absent data, partial data and data: null.
  • Keep the original path even when a parent becomes null.
  • Test permissions, quotas and interface states separately.

Explore GraphQL responses and nullability →

GraphQL Specification · September 2025 · Published edition · September 2025

API-Abkündigung und Stilllegung

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Plan retirement beyond the version number

A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.

  • Distinguish Deprecation, Sunset and policy links.
  • Check that Sunset does not precede Deprecation when both dates are provided.
  • Measure remaining consumers and validate the replacement before cutover.

Compare deprecation and retirement announcements →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23

Weiterführende Quellen

Originaldokumente der Organisationen, die diese Methoden und Standards verantworten.