Aloha ;)
grundsätzlich ist es so, dass ein fetch() oder XMLHttpRequest, der in einem Script von Origin A abgesetzt wird, nur auf Ressourcen des Origin A zugreifen darf.
Das kann man mittels CORS aufweichen (Access-Control-* Header), womit der Server explizit erlauben kann, dass ein Script, das auf einer Seite ausgeführt wird, auch auf Ressourcen von Origin B und C zugreifen darf.
Wenn DU jetzt eine Fake-Seite auf Origin F baust und dort eigene Scripte hast, die im Hintergrund auf Origin A zugreifen und dort Schabernack treiben, hast Du es in der Hand, diesen Zugriff per CORS zu gestatten.
Moment, widersprichst du dir da nicht selbst? Müsste man nicht Zugriff auf Origin A haben, um diesen Zugriff per CORS zu gestatten? Demnach wäre ja dann nur, weil ich die Kontrolle über Origin F habe noch lange kein Zugriff auf Origin A möglich (vorausgesetzt die SOP ist dort korrekt und sinnvoll eingerichtet).
Ich sehe da allerdings ein ganz anderes viel schwerwiegenderes Sicherheitsproblem: SOP und CORS sind Konzepte, die ausschließlich vom Browser umgesetzt werden. Baue ich mir meinen eigenen Pseudo-Browser, der HTTP(S)-Requests absetzt und diese Sicherheitsmaßnahmen nicht implementiert, kann ich da jederzeit drauf pfeifen und fröhlich Daten an Origin A schicken, egal was SOP/CORS dazu sagen.
Und deshalb zur ursprünglichen Frage @OP: Nein, meines Wissens nach hat der Server keine technische Möglichkeit, den Ursprung eines Requests zu verifizieren - außer eben durch das Voraussetzen eines gemeinsamen Secrets zur Authentifizierung wie von Rolf auch hier beschrieben:
Server-Requests benötigen dieses Token und der Server muss stets prüfen, ob die Aktion, die mit diesem Token ausgeführt werden soll, dem Besitzer dieses Tokens auch gestattet ist.
Grüße,
RIDER