Zwischen vielen anderen, häufig in einem Atemzug mit Web 2.0 genannten Schlagworten und Konzepten stechen vor allem die Mashups heraus. Sie benennen die naheliegende Idee der Vermischung diverser Dienste und Datenquellen, die innerhalb einer Webapplikation bisher nur auf dem Server zufriedenstellend zu bewältigen war. Auf dem Client verhindert die „Same Origin Policy“ den Zugriff auf Dokumente aus fremden Domains, die zum Beispiel über Frames eingebunden sein können. So teilen sich seit den seligen Zeiten von Netscape 2.0 alle aus einer Domain stammenden Dokumente eine Sandbox innerhalb der vom Browser bereitgestellen Sandbox. Das macht Sinn, verhindert aber auch, dass aktuelle Implementierungen von XMLHttpRequests auf Resourcen fremder Domains zugreifen. Das verhindert die Kommunikation mit den zahllosen Web-APIs, die mittlerweile auch von Mainstream-Sites angeboten werden. Sie können bisher nur mithilfe von Tricks wie der Kommunikation mittels Query-String oder dem extrem unsicheren Remote Scripting genutzt werden. Der prinzipiell offenen Philosophie von Mashups schiebt der Client so einen Riegel vor, sodass saubere, standardkonforme und auch sicher „gemashte“ Webapplikationen noch Zukunftsmusik sind.

In einem Entwurf beschreibt das W3C nun einen Mechanismus, mit dem HTTP-Requests auf fremde Domains erlaubt werden, sodass nicht sofort die Same Origin Policy zuschlägt. Dafür signalisiert der Server, welchen Domains er den Zugriff gestattet. Das geschieht entweder über einen in der Response gelieferten „Access-Control“ HTTP-Header oder eine im Dokument eingebettete „<?access-control?>“ XML-Processing-Instruction, die vom Browser nacheinander ausgewertet werden. Der Zugriff wird nur dann gestattet, wenn die Host Domain auf ein Muster aus der Positivliste passt und nicht explizit auf eines in der Negativliste.

Die Listen werden durch entsprechende „allow“- oder „deny“-Regeln gebildet, in denen als „Access Items“ bezeichnete simple URI-Pattern definiert werden. Sie dürfen ein Schema, Domain Patterns mit Wildcards und einen Port enthalten.

Access-Control allow <*>
Access-Control allow <http://blog.formatvorlage.de>
Access-Control allow <*.formatvorlage.de> <http://foobar.com>
Access-Control deny <nastyleecher.com:80>
<?access-control allow="*.formatvorlage.de http://foobar.com"?>

Komplexere Setups, die wegen der Priorität der Negativ- vor der Positivliste nicht möglich wären, können mit einem zusätzlichen „exclude“ realisiert werden.

<?access-control allow="*.formatvorlage.de" exclude="*.dev.formatvorlage.de"?>
<?access-control allow="t3.dev.formatvorlage.de"?>

Im angeführten Beispiel dürfen alle Subdomains von „*.formatvorlage.de“ mit Ausnahme von „*.dev.formatvorlage.de“ auf die Ressource zugreifen. Zusätzlich wird der Zugriff „t3.dev.formatvorlage.de“ gestattet.

Die neue Firefox Version 3 unterstützt die neue Technologie ab dem Developer-Release Alpha 7. Beim Testen des HTTP-Headers mit Firefox ist darauf zu achten, dass als HTTP-Header zurzeit noch „Content-Access-Control“ anstatt „Access-Control“ verwendet wird. In Firebug ist zu beobachten, wie jeder Request, unabhängig vom Ziel, ausgeführt wird. Lediglich die Properties „resultText“ und „resultXML“ enthalten bei nicht gestattetem Zugriff einen Leerstring, „status“ und „statusText“ enthalten aber keinen Hinweis.

Es mag auf den ersten Blick paradox erscheinen, doch die Spezifikation trägt langfristig nicht nur zu einem offeneren, sondern auch zu einem sichereren Web bei. Das gilt vor allem in Hinblick auf die dadurch möglich gewordene Ablösung von JavaScript-On-Demand, bei dem mit dynamischen <script>-Elementen der Zugriff auf fremde Ressourcen auch heute bequem möglich ist. Das ist allerdings bei nicht vertrauenswürdigen Quellen eine äußerst unsichere Methode, weil dadurch auf einfache Weise Code in eine Applikation eingeschleust werden kann.

Die Arbeit des W3C stellt einen Schritt in die richtige Richtung dar, es sind aber weiterhin Fragen offen. Auch wenn der Mechanismus prinzipiell unabhängig ist, bleibt seine Wirkung auf die Verwendung von XMLHttpRequests beschränkt. Sie liefert aber keinen Status zurück, sodass die Same Origin Policy für die Kommunikation zwischen verschiedenen Frames weiterhin bestehen bleibt. Um dieses Manko zu überwinden, schlägt der JSON-Erfinder Douglas Crockford das Element <module> vor, das vergleichbar einem Iframe fremde Inhalte einbindet und die kooperative Kommunikation mittels „send/receive“-Methoden und JSON gestattet. Seiner Feststellung, dass die Webapplikationsentwicklung mittlerweile einen signifikanten Vorsprung vor der Browsertechnologie besitzt und ein differenzierteres Sicherheitsmodell benötigt, ist folglich nichts hinzuzufügen. Vor dem Hintergrund des großen Interesses an diesem Thema und der zahlreichen Diskussionen über mögliche Lösungsansätze sind aber bereits in naher Zukunft weitere spannende Entwicklungen zu erwarten.

Der Autor

Claus Augusti arbeitet seit mehr als zehn Jahren als Entwickler, Autor und Dozent im Bereich Web Development und User Interface Design. Am Web fasziniert ihn die Interaktion zwischen Menschen und seine Leidenschaft zielt auf JavaScript und die Mozilla Platttform. In seinem Blog (http://blog.formatvorlage.de) hält er fest, was gerade durch seinen Kopf geht.