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
 nicht angemeldet
 nicht angemeldet Camping_RIDER
 Camping_RIDER Rolf B
 Rolf B