Edge-Funktionen und Server Actions — ohne PHP-Server

Würdigung — der Mini-Backend ohne klassischen Server#

Klassische CMS-Sites wie WordPress haben einen Server, der bei jeder Seitenanfrage Code ausführt — auch dort, wo gar kein dynamischer Inhalt nötig ist. Dieser dauerhaft laufende Server ist die historische Quelle der meisten Sicherheits-Probleme: Plugin-Lücken, SQL-Injections, Server-Konfigurations-Fehler. Eine statisch gerenderte Site hat keinen solchen Dauer-Server — das HTML kommt aus dem CDNCDN · zum GlossarContent Delivery Network — globales Netzwerk an Edge-Servern, das statische Inhalte ortsnah ausliefert., der Browser bekommt fertige Dateien.

Aber: Ein Kontaktformular ist Dynamik. Es nimmt Eingaben entgegen, sendet eine Mail, will gegen Spam geschützt sein. Wie geht das ohne Dauer-Server? Die moderne Antwort heißt: Code-Schnipsel, die nur bei genau dieser Aktion ausgeführt werden, danach wieder verschwinden. Das sind Edge-Funktionen und Server Actions — kleine, präzise abgegrenzte Funktionen, die das Formular-Verarbeiten machen und sonst nichts.

Was sind Edge-Funktionen und Server Actions?#

Beide Begriffe beschreiben dasselbe Grund-Prinzip: serverseitiger Code, der bei einer Anfrage hochgefahren, ausgeführt und danach beendet wird — kein Dauer-Server. Sie unterscheiden sich in den Details:

• Edge-Funktionen laufen nicht in einem einzelnen Rechenzentrum, sondern in der CDN-Infrastruktur des Hosting-Anbieters — bei Vercel z. B. weltweit auf etwa hundert Knoten. Die Funktion wird im Knoten ausgeführt, der dem Besucher am nächsten ist, also extrem schnell. Klassischer Einsatz: API-Endpunkte, OG-Image-Generierung, Authentifizierungs-Checks.
• Server Actions sind eine Next.js-Spezifität: Funktionen, die im Komponenten-Code als serverseitige Aktionen markiert sind und vom Browser direkt aufgerufen werden können, ohne dass ein separater API-Endpunkt definiert werden muss. Sie laufen in einer Serverless-Funktion bei VercelVercel · zum GlossarHosting-Plattform für moderne Web-Apps — Standard-Heimat für Next.js-Sites mit EU-Region. (entweder Edge oder Node.js, je nach Konfiguration). Klassischer Einsatz: Formular-Submissions, Datenbank-Mutationen.

Beide Modelle haben gemeinsam: Sie existieren nur während der Ausführung. Was nicht läuft, kann nicht angegriffen werden — eine fundamentale Sicherheits-Vereinfachung gegenüber dem klassischen Server.

Das Kontaktformular auf fahoch2.de — Schritt für Schritt#

Der Weg einer Kontakt-Anfrage:

1. Besucher tippt Name, E-Mail und Nachricht in das Formular. Das Formular selbst ist statisches HTML aus dem CDN — keine Server-Last bis hier.
2. Beim Absenden ruft der Browser eine Server Action auf — eine Funktion in unserer Codebasis, die als „serverseitig" markiert ist. Vercel startet eine Serverless-Funktion (in Millisekunden), die die Eingabe entgegennimmt.
3. Honeypot-Check. Das Formular hat ein verstecktes Feld, das normale Besucher nie ausfüllen, Bots dagegen häufig. Wenn das Feld einen Wert enthält, beendet die Funktion still — die Anfrage wird verworfen, der Bot bekommt keine Fehlermeldung, die er auswerten könnte.
4. Rate-Limit-Check über Upstash. Pro IP-Adresse erlauben wir eine begrenzte Anzahl Anfragen pro Stunde. Die Funktion fragt einen Upstash-Redis-Counter (in der EU-Region), erhöht ihn und bricht ab, wenn die Schwelle überschritten ist.
5. Validierung der Eingaben. Pflichtfelder gefüllt? E-Mail-Format gültig? Nachricht-Länge plausibel? Diese Prüfungen passieren ebenfalls in der Funktion.
6. Mail-Versand über Resend. Eine HTTPS-Anfrage an die Resend-API schickt die Anfrage als E-Mail an unsere Mandanten-Adresse. Die Funktion wartet auf die Bestätigung und gibt dann den Erfolg an den Browser zurück.
7. Funktion beendet sich. Kein Dauer-Zustand, keine Datenbank, keine laufende Anwendung.

Der ganze Vorgang dauert in der Regel unter 500 Millisekunden. Eine erfolgreiche Übermittlung führt zu einer Bestätigung im Browser, eine fehlgeschlagene zu einer freundlichen Fehlermeldung.

Drei Anwendungs-Fälle für Kanzlei-Sites#

Edge-Funktionen und Server Actions sind nicht nur fürs Kontaktformular nützlich. Drei weitere Standard-Einsätze auf Kanzlei-Sites:

• URL-Audit-Tool. Unser kostenfreies URL-Audit (Eingabe einer Kanzlei-Website, automatische Stichproben-Analyse) ist eine längere Edge-Funktion, die HTTP-Anfragen ausführt und einen Bericht erzeugt — ohne dass dafür ein dauerhafter Server nötig wäre.
• OG-Image-Generierung pro Seite. Auf fahoch2.de generieren wir pro Insight, pro Stadt-Landingpage und pro Audit-Report ein eigenes Open-Graph-Bild — über Edge-Funktionen, die das Bild zur Lauf-Zeit aus Text und Komponenten rendern.
• Newsletter-Anmeldung / Lead-Capture. Die Strecke „Formular → CRM oder Newsletter-Tool" läuft analog zum Kontaktformular: Server Action nimmt entgegen, prüft, leitet via APIAPI · zum GlossarApplication Programming Interface — Schnittstelle, über die Programme miteinander sprechen. an das Ziel-System weiter — alles ohne dauerhaft laufenden Server.

Sicherheits-Schichten ohne CAPTCHA#

Bewusst NICHT auf der Site: Google reCAPTCHAreCAPTCHA · zum GlossarGoogles Bot-Schutz — funktional, aber DSGVO-kritisch wegen US-Datentransfer und Cookie-Pflicht.. Aus DSGVO-Sicht problematisch (Google sieht jeden Besucher), nutzungs-feindlich (Captcha-Aufgaben nerven) und reagiert oft falsch (echte Mandanten werden blockiert). Unsere Alternative — bewusst minimalistisch:

• Honeypot-Feld (verstecktes Input, das Bots oft ausfüllen). Effektiv gegen alle einfachen Spam-Bots, kostet den Besucher null Wahrnehmung.
• Upstash-Rate-Limit (Anzahl Anfragen pro IP und Stunde begrenzt). Schützt gegen aggressive Bots, die das Honeypot umgehen.
• Server-seitige Validierung (Eingabe-Längen, E-Mail-Format, Pflichtfelder). Fängt strukturell unsinnige Anfragen ab.
• Optional: CloudflareCloudflare · zum GlossarUS-Anbieter für CDN, WAF, DDoS-Schutz und Turnstile — Privacy-by-Design-Ausrichtung. TurnstileTurnstile · zum GlossarCloudflares cookieloser reCAPTCHA-Ersatz — Privacy-by-Design, EU-routbar, ohne Tracking. als zweite Schicht für Sites mit hohem Spam-Druck — DSGVO-konformer Captcha-Ersatz ohne Bilderpuzzle.

Tiefer dazu: Form-Spam-Bot-Abwehr-Insight.

Warum das eine Klasse von Angriffen ausschließt#

Drei klassische Angriffsklassen, die in dieser Architektur strukturell nicht existieren:

• SQL-Injection. Es gibt keine Datenbank, also auch keine SQL-Anfragen, die manipuliert werden könnten.
• Plugin-Lücken im CMS. Es gibt kein CMS mit Plugin-System; jeder Code-Strich ist von uns geschrieben und versioniert.
• Server-Konfigurations-Fehler. Es gibt keinen dauerhaft laufenden Server, der falsch konfiguriert sein könnte; die Funktionen starten in einer standardisierten Umgebung, die der Hosting-Anbieter pflegt.

Das ist nicht keine Angriffsfläche, aber eine deutlich kleinere und besser eingegrenzte. Was bleibt: Input-Validierung in der Server Action selbst, Rate-Limit gegen Brute-Force, Schutz der API-Schlüssel (Mail-Provider, Upstash) als Umgebungsvariablen, die nie im Browser sichtbar werden.

Wie wir es bauen#

Bei jedem Kanzlei-Projekt richten wir das Kontaktformular standardmäßig als Server Action ein, mit Honeypot, Rate-Limit über Upstash (EU-Region), Resend für den Mail-Versand und voller Validierung. Die API-Schlüssel leben als Umgebungsvariablen bei Vercel — nicht im Code, nicht im Repo. Der gleiche Ansatz skaliert für Newsletter-Anmeldung, Lead-Capture und kleine API-Tools. Wer mehr Schichten braucht (z. B. eingebundener Mandanten-Login), schiebt das in eigenständige Backend-Services — die Site selbst bleibt statisch + Edge-Funktionen, was die Wartbarkeit hoch hält.

Für eine strukturierte Bewertung der Formular- und Backend-Architektur einer bestehenden Kanzlei-Site empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Eine moderne, statisch gerenderte Kanzlei-Website braucht für ihr Kontaktformular keinen klassischen Webserver. Edge-Funktionen und Server Actions sind kleine, präzise abgegrenzte Funktionen, die bei einer Anfrage starten, sie verarbeiten und sich beenden — kein Dauer-Zustand, kein Plugin-System, keine Datenbank. Auf fahoch2.de läuft das Kontaktformular als Server Action mit Honeypot-Spam-Abwehr, Rate-Limit über Upstash (EU-Region), Server-seitiger Validierung und Mail-Versand via Resend. Die ganze Strecke dauert unter 500 Millisekunden und schließt drei klassische Angriffsklassen strukturell aus: SQL-Injection (keine Datenbank), Plugin-Lücken (kein Plugin-System), Server-Konfigurations-Fehler (kein Dauer-Server). Was bleibt — Input-Validierung, Rate-Limit, API-Schlüssel-Schutz — ist enger gefasst und besser handhabbar. Für Kanzlei-Sites die strukturell sicherste Form, ein funktionierendes Kontaktformular zu betreiben.

Quellen#

• Next.js — Server Actions Documentation — abgerufen 2026-06-05
• Vercel — Functions Overview — abgerufen 2026-06-05
• Upstash — Redis Rate Limit Documentation — abgerufen 2026-06-05
• Resend — Email API Documentation — abgerufen 2026-06-05
• OWASP — Top 10 Web Application Security Risks — abgerufen 2026-06-05

Disclaimer: Beschreibung der tatsächlichen Kontaktformular-Architektur von fahoch2.de zum Zeitpunkt der Veröffentlichung. Konkrete Implementierungen variieren je nach Hosting-Plattform und Mail-Anbieter; das Prinzip „kein Dauer-Server, präzise abgegrenzte Funktionen" bleibt gleich.