Es besteht keine SOC-2-, ISO-27001- oder andere Zertifizierung.
Produkt wählen
WebhostingWebsites und WordPress in einem Tarif mit FestpreisCloudApps, APIs und Datenbanken aus Git oder Docker deployenAI BuilderWebsites und Apps mit KI erstellen und ändernZu jedem Projekt hinzufügen
Domains & E-MailDatenbankenManaged WordPressAgent-LaufzeitenMigrationenEntwickler
Alles zu KIEntwicklerMCP für KI-AssistentenDokumentationSicherheitStatusHostingsurge
PreiseAnmeldenSicherheit
Isolation und verifizierte Arbeit, von Grund auf.
Diese Seite beschreibt, wie die Plattform von Hostingsurge tatsächlich gebaut ist: die Datenbankgrenze, die Sitzungsgrenze, die Build-Sandbox und der Zahlungsweg. Sie nennt keine Zertifizierung und kein Audit, weil es keine gibt.
Mandantenisolation in der Datenbank
Die Isolation wird dort durchgesetzt, wo die Daten liegen – nicht nur im Anwendungscode.
- Jede mandantensensible Tabelle hat eine Organisation als Eigentümerin (organization_id oder eine gleichwertige Mandantengrenze) mit zusammengesetzter Eigentümerschaft bis zu den Projekten.
- Row-Level Security ist für Mandantentabellen erzwungen, und die Laufzeitrollen sind eng gefasst: Die Identitätsrolle kann keine Projekt- oder Wallet-Daten lesen, und die Anfragegrenze weist administrative PostgreSQL-Rollen, Superuser-Rollen sowie Rollen mit Datei- oder Serverrechten ab.
- Der Mandantenkontext wird pro Transaktion gesetzt. Eine Kennung, die aus einem Browser kommt, ist eine Anfrage – niemals eine Autorisierung.
- Geschützte Schreibvorgänge laufen über Funktionen, die Sitzung und aktuelle Berechtigung unabhängig prüfen, und direkte Schreibrechte von Anwendungsrollen sind für diese Tabellen entzogen.
Sitzungen und aktuelle Berechtigung
Die Authentifizierung wird beim Eintritt geprüft, und die Berechtigung wird in dem Moment erneut geprüft, in dem sie genutzt wird.
- Sitzungscookies sind HttpOnly und SameSite=Lax, in der Produktion mit __Host-Präfix, und jede Anfrage ordnet die Sitzung einem Benutzer und einem Mandanten zu, bevor irgendetwas anderes passiert.
- Ändernde Anfragen aus dem Browser müssen vom konfigurierten Origin kommen, und Anfragekörper sind begrenzt (application/json, 16 KiB, fünf Sekunden Frist).
- Sensible Änderungen – MFA-Änderungen, das Ausstellen von Zugangsdaten, Käufe, Tarifwechsel – erfordern eine frische Authentifizierung statt einer langlebigen Sitzung.
- MFA ist TOTP mit einmaligen Wiederherstellungscodes. Tokens und Codes werden atomar verbraucht, sodass zwei gleichzeitige Verwendungen nicht beide erfolgreich sein können.
Zugangsdaten und Freigaben von Vorgängen
Zugangsdaten sind eine eng begrenzte, widerrufbare Berechtigung – kein dauerhafter Schlüssel zur Plattform.
- API- und MCP-Zugangsdaten werden gehasht gespeichert, an genau eine Organisation, eine Marke und ein Projekt gebunden, tragen explizite Scopes und eine begrenzte Lebensdauer und werden genau einmal angezeigt.
- Wird jemand aus einem Team entfernt, werden seine Zugangsdaten dauerhaft widerrufen, und ein Zurücksetzen des Passworts macht zuvor ausgestellte Zugangsdaten ungültig.
- Sensible und kostenpflichtige Aktionen erfordern eine kurzlebige Freigabe, die an Benutzer, Organisation, Projekt, die genaue Aktion, das Ziel und den kanonischen Digest der Eingabe gebunden ist.
- Verbrauch der Freigabe, Zulassung des Jobs, Reservierung der Credits, Audit und der Outbox-Eintrag werden in einer einzigen Transaktion committet; schlägt der vertrauenswürdige Callback fehl, wird die gesamte Zulassung zurückgerollt. Rollen- oder Mitgliedschaftsänderungen widerrufen ausstehende Freigaben dauerhaft.
Builds laufen isoliert
Kundencode und KI-generierter Code werden als nicht vertrauenswürdig behandelt, weil sie es nicht sind.
- Builds laufen in einem temporären Container auf einem minimalen Basis-Image mit deaktiviertem Netzwerk, begrenztem Arbeitsspeicher und CPU, einem Prozesslimit, einem schreibgeschützten Root-Dateisystem, einem begrenzten temporären noexec-Mount, ohne Docker-Socket und ohne Produktionszugangsdaten, unter einem Wall-Clock-Timeout.
- Ein Artefakt muss die Digest- und Größenprüfung bestehen und über einen atomaren Speicher geschrieben werden – schreiben, flushen, zurücklesen, atomar umbenennen, erneut zurücklesen –, bevor eine Build-Quittung erfasst wird. Ein Absturz kann daher nie einen Bereit-Zustand ohne dauerhaft gespeicherte Bytes hinterlassen.
- Build- und Artefakt-Quittungen sind append-only; ein Update oder Löschen löst einen Unveränderlichkeitsfehler aus.
- Ein Worker hält eine Lease mit Fencing, verlängert sie, während er arbeitet, und stoppt, wenn er die Eigentümerschaft verliert. Quell- und Archivgrenzen (1000 Einträge, 256 KB pro Datei, 16 MB insgesamt) werden beim Eingang und beim Ausgang durchgesetzt.
- Dateiinhalte werden als escapter Text an den Browser ausgeliefert: Markup in einer gespeicherten Datei bleibt wirkungslos und wird nie ausgeführt.
Zahlungen, verifiziert anhand signierter Ereignisse
Geld bewegt sich nur, wenn der Anbieter es sagt – und die Plattform kann es beweisen.
- Zahlungs-Webhooks werden mit echter Signaturprüfung über den begrenzten, rohen Request-Body verifiziert, mit Replay- und Zeitprüfungen sowie einem exakten Konto- und Test/Live-Bereich. Der Endpunkt bestätigt nur einen dauerhaft gespeicherten Empfang.
- Credits werden erst dann zu einem Guthaben, wenn die Zahlung beim Anbieter verifiziert wurde – Rechnung, Payment Intent und Charge –, und eine Gutschrift wird genau einmal angewendet.
- Preise werden nie aus einem Browser übernommen: Beträge und Credit-Einheiten stammen aus einem serverseitigen Katalog, und ein Preis, der nicht zu erwartetem Produkt, Betrag, Währung und Abrechnungszyklus passt, wird abgelehnt.
EU-Hosting und dokumentierte Härtung
Was heute zutrifft – einschließlich dessen, was noch nicht fertig ist.
- Die Server stehen in der EU und werden von der Plattform verwaltet. Kunden erhalten nie ein Control Panel eines Anbieters; alles läuft über Hostingsurge.
- Auf dem Produktionsserver wurden ausstehende Betriebssystem-Updates installiert (einschließlich Sicherheitsupdates), die Firewall wurde aktiviert, wobei SSH, HTTP, HTTPS und HTTP/3 erhalten blieben, und die Administrationsbindung des Reverse Proxys wurde auf localhost beschränkt und nach einem Neustart überprüft.
- Der Datenverkehr wird über TLS und einen gehärteten Proxy terminiert; Administrationsoberflächen sind nicht aus dem Internet erreichbar.
- Die Steuerungsdatenbank wird alle 24 Stunden auf Speicher desselben Servers gesichert und 14 Tage aufbewahrt. Die verschlüsselte externe Kopie (off-site) ist gebaut, aber ihr Speicher-Bucket ist noch nicht angebunden, deshalb bleiben die Backups vorerst auf dem Server – das wird hier ausdrücklich gesagt statt nur angedeutet.
Was diese Seite nicht behauptet
Klar gesagt, denn eine Sicherheitsseite, die übertreibt, ist schlimmer als keine.
Es wurde kein unabhängiges Sicherheitsaudit durchgeführt.
Es gibt keinen Bericht über einen Penetrationstest durch Dritte.
Es werden kein Uptime-SLA und kein Bug-Bounty-Programm angeboten.
Es ist noch keine Adresse für die Meldung von Sicherheitslücken veröffentlicht. Bis es eine gibt, hat ein Fund keinen bestätigten Kanal – und diese Seite wird sie nennen, sobald sie existiert.
Erst die Grenzen lesen, dann entscheiden.
Die Entwicklerseite dokumentiert die echten Endpunkte und ihre Authentifizierung. Die Dokumentation zeigt Modul für Modul, was implementiert ist.
Alles oben Genannte beschreibt den aktuellen Build. Nirgendwo auf dieser Website wird eine Zertifizierung, ein Audit oder ein SLA behauptet.