Warum ich das Thema ernst nehme

Access spricht gern mit dem Web – per REST, per ODBC, per FTP.
Aber Access prüft nix von sich aus.
Wenn Du da keine Leitplanken setzt, ist die Tür offen – weit offen.
Ich zeige Dir, wie ich solche Risiken minimiere, ohne den Nutzen zu verlieren.

1. Keine direkten GET-Anfragen in VBA

Viele machen sowas:

json = HoleJson("https://example.com/api/data")

Das sieht harmlos aus, aber:

• keine Authentifizierung
• keine HTTPS-Prüfung
• kein Schutz gegen Replay oder Injection

Besser: Authentifizierung per Token

Function HoleJsonMitToken(URL As String, Token As String) As String
    Dim http As Object
    Set http = CreateObject("WinHttp.WinHttpRequest.5.1")

    http.Open "GET", URL, False
    http.SetRequestHeader "Authorization", "Bearer " & Token
    http.Send

    If http.Status = 200 Then
        HoleJsonMitToken = http.ResponseText
    Else
        HoleJsonMitToken = ""
    End If
End Function

Den Token speicherst Du nicht in Klartext in der Datenbank.
Sondern z. B. verschlüsselt mit DPAPI oder als verschlüsselte XML in UserTemp.

2. Keine dynamischen SQLs aus dem Web

Ich habe Kollegen gesehen, die sowas tun:

Dim sql As String
sql = HoleJson("https://example.com/sql") ' API liefert SQL zurück
CurrentDb.Execute sql

Das ist lebensmüde.
Dann kannst Du auch gleich DROP TABLE erlauben.

Besser: nur vordefinierte Queries

Zentrale Steuerung via Query-Name und Parameter.

Function FuehreQueryAus(Name As String, ParamArray args() As Variant)
    Dim qdf As DAO.QueryDef
    Set qdf = CurrentDb.QueryDefs(Name)
    
    Dim i As Integer
    For i = 0 To UBound(args)
        qdf.Parameters(i) = args(i)
    Next i

    qdf.Execute
End Function

Damit bleibt die Kontrolle bei Dir – nicht bei der API.

3. Kein Klartext-POST aus Access

Wenn Du per http.Send Daten schickst, schickst Du oft zu viel:

• ganze JSONs mit Namen, IDs, E-Mail, IBAN
• ohne Signatur
• ohne Logging

Besser: Hash mitgeben

Function Signiere(payload As String, geheim As String) As String
    Signiere = Left(CStr(CreateObject("Scripting.FileSystemObject").GetTempName), 8) ' Dummy für Beispiel
End Function

Oder besser: SHA256 aus einem COM-Wrapper.
Dann prüfst Du auf Server-Seite in PHP:

if (hash_equals($_POST['signature'], hash_hmac('sha256', $_POST['payload'], $secret))) {
    // gültig
}

Damit kann niemand von außen einfach was reinschicken.

4. WordPress als API-Gateway absichern

Wenn Du über wp-json arbeitest, dann:

• sperre den Zugriff per IP-Whitelist
• arbeite mit Nonces oder Tokens
• prüfe Referer und User-Agent
• logge alles

Beispiel: PHP-Schutz

function check_access() {
    if ($_SERVER['REMOTE_ADDR'] !== '1.2.3.4') {
        wp_die('Zugriff verweigert', '', ['response' => 403]);
    }
}
add_action('rest_api_init', function () {
    register_rest_route('intern/v1', '/data', [
        'methods' => 'GET',
        'callback' => 'get_data',
        'permission_callback' => 'check_access'
    ]);
});

5. Auditing in Access selbst

Ich logge alle externen Zugriffe in eine Tabelle:

Zeitpunkt	Richtung	URL	Status	Nutzer	Requestgröße	Antwortgröße

Sub LogZugriff(richtung As String, url As String, status As String, sizeIn As Long, sizeOut As Long)
    CurrentDb.Execute "INSERT INTO api_log (zeitpunkt, richtung, url, status, requestgroesse, antwortgroesse) " & _
                      "VALUES (Now(), '" & richtung & "', '" & url & "', '" & status & "', " & sizeIn & ", " & sizeOut & ")"
End Sub

So kannst Du auch nachweisen, was wann wohin geflossen ist.

6. Zugriff auf lokale Tabellen begrenzen

Wenn Du externe Daten holst, speicher sie nicht in produktive Tabellen.
Nutze eine tmp_-Tabelle oder ein separates Backend.
Nur geprüfte und bereinigte Daten dürfen rein.

Beispiel:

INSERT INTO tmp_import (name, email)
SELECT name, email
FROM json_import
WHERE email LIKE '*@firma.de'

Nie blind übernehmen.

Datenschäfer sein Fazit

Access ist kein Sicherheitsrisiko – wenn Du es im Griff hast.
Aber Du musst bewusst handeln.
Keine Autoexec-Makros, die alles machen.
Keine offenen URLs.
Und nie blind vertrauen, nur weil’s JSON ist.