Wildcard im Web API: Was am 14. September bricht und wie Sie es jetzt fixen

Worum es technisch geht

Die Portal Web API von Power Pages wird über zwei Site Settings je Tabelle freigeschaltet:

Der Tabellenname im Setting ist der logische Name der Tabelle, also account oder incident. In der URL des Aufrufs steht dagegen der EntitySetName in der Mehrzahl, also /_api/accounts oder /_api/incidents. Diese Unterscheidung ist beim Aufräumen wichtig, weil Sie in den Site Settings nach dem einen und im JavaScript nach dem anderen suchen.

Bisher war im fields-Setting der Wert * erlaubt. Er bedeutet alle Spalten. Bequem beim Bauen, und genau das ist das Problem. Microsoft formuliert es so: der Wildcard-Wert legt alle Spalten einer Dataverse-Tabelle über die Power Pages Web API offen.

Was am 14. September konkret bricht

Alles, was über den /_api/-Pfad auf eine Tabelle zugreift, deren fields-Setting auf * steht. Wo genau das in Ihrem Portal passiert, kann ich von hier aus nicht wissen, das hängt an Ihrer Implementierung und Ihrem Custom Code. Die folgenden vier Kategorien sind deshalb Beispiele, keine vollständige Liste, sie sollen Ihnen beim Suchen eine Richtung geben. Genauso gut kann der Aufruf in einer React-Komponente stecken, in einem Web Template oder in einer Multistep-Form-Konfiguration, die niemand mehr auf dem Schirm hat. Die dritte Kategorie unten ist die, die man am ehesten vergisst:

Nicht betroffen sind serverseitige Integrationen gegen die Dataverse Web API unter /api/data/v9.2/. Das ist eine andere Schnittstelle mit einem anderen Berechtigungsmodell. Betroffen ist ausschließlich der Portal-Pfad /_api/.

So sieht das Fehlerbild konkret aus. Im Demo-Portal habe ich das fields-Setting entfernt und denselben Aufruf wiederholt: Antwort HTTP 403, Fehlercode 90040101, Meldung "Attribute contactid in table contact is not enabled for Web Api." (der genannte Spaltenname wechselt je nachdem, welche Spalte der Aufruf anfragt). Das ist der belegte Fall des fehlenden Settings. Der Wildcard-Fall nach dem 14. September sieht sehr wahrscheinlich, aber nicht garantiert genauso aus, denn beide Fälle laufen technisch auf dasselbe hinaus: keine Spalte in der Antwort ist als erlaubt hinterlegt.

Hands-on: Wildcard gegen explizite Spaltenliste

Der Unterschied lässt sich in wenigen Minuten sichtbar machen. Der folgende Ablauf ist so beschrieben, dass Sie ihn in Ihrer eigenen Entwicklungsumgebung nachstellen können. Alle Zahlen und Fehlermeldungen unten sind im Demo-Portal von powerportals.de gemessen, nicht angenommen.

Ausgangslage herstellen

Legen Sie in der Portal Management App zwei Site Settings für eine Tabelle Ihrer Wahl an. Im Beispiel contact:

Webapi/contact/enabled   →  true
Webapi/contact/fields    →  *

Vergeben Sie außerdem eine Table Permission mit Leserecht auf contact für die Web Role, unter der Sie testen. Ohne Table Permission bekommen Sie einen Berechtigungsfehler, nicht das Verhalten, das Sie sehen wollen.

Nach jeder Änderung an Site Settings rufen Sie /_services/about auf und lösen Clear Cache aus. Ohne Cache-Invalidierung messen Sie den alten Zustand.

Der Aufruf

Für lesende Aufrufe reicht tatsächlich die Adresszeile Ihres Browsers. Angemeldet am Portal einfach die URL direkt aufrufen:

https://IhrPortal.powerappsportals.com/_api/contacts?$top=1&$select=contactid,firstname,lastname,emailaddress1

Der Browser zeigt die JSON-Antwort direkt an, kein Werkzeug nötig. Ich zeige den Ablauf trotzdem über die Browser-Konsole, weil sich damit auch die Spaltenzahl automatisch auszählen und formatieren lässt, und weil dieselbe Technik für schreibende Aufrufe (POST, PATCH) sowieso nötig ist, die über die Adresszeile nicht gehen. In der Konsole, angemeldet am Portal:

fetch("/_api/contacts?$top=1&$select=contactid,firstname,lastname,emailaddress1", {
  headers: { "Accept": "application/json" }
})
  .then(r => r.json())
  .then(d => {
    const rec = d.value[0];
    console.log("Spalten in der Antwort:", Object.keys(rec).length);
    console.log(Object.keys(rec).sort());
  });

Für schreibende Aufrufe brauchen Sie zusätzlich das CSRF-Token. Die von Microsoft dokumentierte Wrapper-Funktion webapi.safeAjax holt es intern über shell.getTokenDeferred() und setzt daraus den Header __RequestVerificationToken, das ist der aktuelle, gegen Microsoft Learn geprüfte Stand. Lesende GET-Aufrufe, wie oben, funktionieren auch ohne.

Vorher: fields = *

Die Demo-Website ist am 16. August 2026 angelegt worden, also nach dem Stichtag im August, ab dem Microsoft neu erstellten Websites den Wildcard-Wert komplett verweigert. Der Aufruf mit fields = * liefert dort deshalb schon heute keinen Spaltensatz, sondern einen Fehler: HTTP 403, Code 90040122, Meldung "You are unauthorized to process this request." Dieser Code steht noch nicht in Microsofts offizieller Fehlercode-Tabelle für die Web API, vermutlich weil er erst mit der Wildcard-Sperre neu dazugekommen ist. Das ist kein Sonderfall der Zukunft, das ist der aktuelle Zustand jeder Website, die seit August 2026 entstanden ist.

Auf Websites, die vor diesem Stichtag angelegt wurden, funktioniert der Wildcard-Wert nach aktuellem Stand noch, bis die Unterstützung am 14. September für alle entfernt wird. Wie viele Spalten eine solche ältere Website konkret zurückliefert, kann ich an dieser Stelle nicht zeigen, weil die einzige verfügbare Demo-Website selbst schon zur neuen Kategorie zählt. Rechnen Sie bei einer Standard-Kontakttabelle mit eigenen Feldern mit einem hohen zweistelligen bis dreistelligen Wert, das lässt sich in Ihrer eigenen, älteren Umgebung in einer Minute nachmessen.

Nachher: explizite Liste

Ändern Sie das Setting auf die Spalten, die Ihre Seite tatsächlich braucht:

Webapi/contact/fields  →  contactid,firstname,lastname,emailaddress1

Cache invalidieren, Aufruf mit passendem $select wiederholen. Die Antwort enthält jetzt exakt die vier angeforderten Spalten plus das Verwaltungsfeld @odata.etag, gemessen also fünf Einträge im JSON, nichts weiter. Die Seite funktioniert unverändert, die Angriffsfläche ist auf das reduziert, was Sie tatsächlich abgefragt haben.

In das Setting gehören die Schemanamen der Spalten, nicht die Anzeigenamen. Das kostet beim Umstellen Zeit. emailaddress1, nicht "E-Mail". Bei eigenen Spalten also inklusive Präfix, etwa new_kundennummer. Die Attribut-Auswahl-Controls im modernen Konfigurationserlebnis geben Ihnen die Liste kommasepariert aus, das spart Tipparbeit und Tippfehler.

Der 10-Minuten-Selbstcheck

Sie brauchen dafür Zugriff auf die Portal Management App und eine Liste Ihrer Portale. Rechnen Sie zehn Minuten pro Portal.

Schritt 1: Site Settings filtern

Öffnen Sie die Portal Management App, dann Site Settings. Filtern Sie die Spalte Name auf den Textbestandteil Webapi/. Sie sehen jetzt alle Web-API-Einstellungen dieser Website. Im Design Studio finden Sie dieselben Einträge unter den Website-Einstellungen, die Portal Management App ist für diesen Zweck aber schneller, weil sie sortier- und filterbare Rasteransichten hat.

Schritt 2: Auf den Wert schauen

Sortieren oder filtern Sie zusätzlich auf Value gleich *. Jeder Treffer ist ein Fundstück. Notieren Sie den Tabellennamen aus dem Setting-Namen.

Schritt 3: Kein Treffer ist noch kein Ergebnis

Wenn Sie mehrere Websites in der Umgebung haben, prüfen Sie, ob der Filter auf die richtige Website eingeschränkt ist. Site Settings sind websitebezogen, und in einer Umgebung mit Dev, Test und Prod stehen drei Datensatzsätze nebeneinander. Prüfen Sie alle drei, denn kaputt geht später die Produktion.

Schritt 4: Je Fundstück die genutzten Spalten ermitteln

Für jede betroffene Tabelle brauchen Sie die Liste der Spalten, die Ihr Code tatsächlich liest oder schreibt. Zwei Wege führen dahin: Durchsuchen Sie Ihre Web Templates, Web Files und Content Snippets nach dem Tabellennamen im Plural, also /_api/contacts, und lesen Sie die verwendeten Felder aus $select und aus den Payloads der Schreibaufrufe ab. Alternativ öffnen Sie die betroffene Portalseite und beobachten die Aufrufe im Netzwerk-Tab. Das ist der ehrlichere Weg, weil er auch Code erfasst, den Sie nicht mehr auf dem Schirm haben.

Schritt 5: Umstellen, invalidieren, testen

Setting auf die ermittelte Liste ändern, /_services/about und Clear Cache, dann die betroffenen Seiten durchklicken. Vergessen Sie die Schreibpfade nicht: ein $select verrät Ihnen nur die gelesenen Spalten. Was ein POST oder PATCH schreibt, steht im Request Body.

Schritt 6: Nachziehen in allen Umgebungen

Site Settings sind Konfigurationsdaten. Nehmen Sie die Änderung in der Solution mit, damit sie den Weg nach Test und Produktion findet und den nächsten Deployment-Zyklus überlebt.

Einordnung: Warum das eine Sicherheitsänderung ist

Microsoft begründet die Änderung mit Sicherheit und Wartbarkeit. Die Formulierung in der Dokumentation: Die Verwendung des Wildcard-Werts kann unbeabsichtigt zusätzliche Spalten über die Power Pages Web API offenlegen. Eine explizite Liste stellt sicher, dass nur die beabsichtigten Daten zugänglich sind.

Das ist präzise formuliert und trifft einen Punkt, den ich in Security Audits regelmäßig sehe. Die Web API hängt an drei Kontrollebenen: der Web Role des Nutzers, den Table Permissions und den Column Permissions. Wer alle drei sauber gesetzt hat, für den ist der Wildcard kein Loch, sondern nur unordentlich. Das Problem ist der praktische Normalfall: Table Permissions werden auf Tabellenebene vergeben, Column Permissions bleiben oft ungenutzt, weil sie in der Anfangsphase Reibung erzeugen. Dann ist der Wildcard die eine Zeile Konfiguration, die entscheidet, ob ein angemeldeter Portalnutzer über die Konsole zwölf Spalten sieht oder hundertzwanzig.

Das Interessante am Aufräumen ist deshalb weniger der Fix selbst als das, was dabei sichtbar wird. Fast jedes Portal, das ich mir ansehe, hat mindestens eine Web-API-Tabelle, von der niemand im Team mehr weiß, wofür sie freigeschaltet wurde. Der 14. September ist ein guter Anlass, diese Liste einmal ehrlich durchzugehen.

Wenn Sie bei der Gelegenheit wissen wollen, wie es um die anderen beiden Ebenen steht, ist das genau der Umfang eines Security Audits: Table Permissions, Column Permissions, Web Roles, Authentifizierung und die Frage, welche Daten ein angemeldeter Nutzer tatsächlich abrufen kann, wenn er es darauf anlegt. Festpreis ab 4.900 Euro netto, Ergebnis ist ein Befundbericht mit Schweregraden und Reihenfolge, keine Liste mit 200 Zeilen Werkzeugausgabe.

Was Sie jetzt tun sollten

Bis zum 14. September 2026 sind es vier Wochen. Die Reihenfolge, die ich empfehle:

1. Heute den Selbstcheck oben durchführen, für jedes Portal, jede Umgebung. Ergebnis ist eine Liste betroffener Tabellen.
2. Diese Woche die Spaltenlisten ermitteln und in Dev umstellen.
3. Nächste Woche über Test nach Produktion ziehen, mit Regressionstest auf den betroffenen Seiten.
4. Danach den Puffer bis zum 14. September für das behalten, was dabei auffällt.

Warten Sie nicht bis kurz vor Schluss. Microsoft schreibt es selbst in die Dokumentation: Nicht warten, bis die Unterstützung entfernt wird, sondern die Site Settings so bald wie möglich aktualisieren.

Warum meine Wartungskunden das schon wussten

Meine Wartungskunden hatten diese Information am Ankündigungstag auf dem Tisch, mit der Liste ihrer betroffenen Tabellen dabei. Nicht weil ich schneller lese als andere, sondern weil der Release-Check bei Power Pages Care zum Vertrag gehört.

Ich kümmere mich um Ihr Portal, damit Sie es nicht tun müssen. Das ist kein Support-Vertrag mit Stundenkontingent. Vier Dinge passieren jeden Monat, ob gerade etwas los ist oder nicht.

Care kostet 1.290 Euro netto im Monat, mit 48 Stunden Reaktionszeit an Werktagen und Anpassungen bis zwei Stunden im Monat. Care Plus kostet 2.490 Euro netto und enthält zusätzlich einen Quartals-Deep-Dive über je einen Auditbereich, 24 Stunden Reaktionszeit, am selben Tag bei Sicherheitsvorfällen, und Anpassungen bis fünf Stunden. Mindestlaufzeit drei Monate, danach monatlich kündbar.

Der Deep-Dive folgt den acht Bereichen des Security Audits, über zwei Jahre entsteht daraus ein rollierendes Vollaudit. Wenn Sie kündigen, bleiben Reports und Dokumentation bei Ihnen.

Ein Portal ohne diesen Blick erfährt von Änderungen wie dieser an dem Tag, an dem das Formular nicht mehr speichert. Das ist der ganze Unterschied.

Sie wissen immer, wer zuständig ist. Onepager und Konditionen: powerportals.de. Fragen dazu gern direkt an tino@amingi.net.

Weiterführende Artikel

Quellen

• Important upcoming changes and deprecations in Power Pages, Abschnitt "Wildcard value (*) in Web API field configuration", Dokumentstand 14.08.2026
• Overview of the Power Pages portals Web API, Site Settings, Endpunkt-Aufbau, Tabellen- und Spaltenberechtigungen
• Assign table permissions
• Column permissions
• Compose HTTP requests and handle errors for the portals Web API, Fehlercode-Tabelle (Code 90040101 dort dokumentiert, Code 90040122 aus dem Demo-Test nicht)