Die Lösung des CORS-Dilemmas: Ein ausführlicher Blick auf die Cross-Origin-Ressourcenfreigabe

Wenn Sie ein Backend-Entwickler sind, sind Sie möglicherweise schon einmal auf dieses Szenario gestoßen: Sie testen Ihre API-Endpunkte mit Postman, Swagger oder einem anderen Tool, und alles scheint reibungslos zu funktionieren. Sobald jedoch der Frontend-Entwickler beginnt, die API zu nutzen, berichten sie, dass CORS-Fehler auftreten.

In dem Bemühen, den Frontend-Entwickler zufriedenzustellen, haben Sie möglicherweise den Header Access-Control-Allow-Origin mit dem Wert "*" aktiviert, um Anfragen von jedem Ursprung zuzulassen. Obwohl dieser Ansatz das Problem vorübergehend lösen könnte, kann er auch Sicherheitslücken schaffen und potenziell sensible Daten unbefugten Parteien preisgeben.

In diesem Artikel werden wir einen umfassenden Blick auf CORS im Kontext des AWS API Gateway werfen und bewährte Methoden zur Konfiguration von CORS-Einstellungen erkunden, um sowohl Sicherheit als auch Zugänglichkeit zu gewährleisten. Wir werden jeden Abschnitt im Detail durchgehen.

• Was ist CORS?

• Warum wird CORS benötigt?

• Art der Browser-Anfragen

• Wie konfiguriere ich CORS in der API Gateway mit dem Serverless Framework?

Was ist CORS?

Gemäß der Definition von MDN:Cross-Origin Resource Sharing (CORS)CORS (Cross-Origin Resource Sharing) ist ein auf HTTP-Headern basierender Mechanismus, der es einem Server ermöglicht, beliebige Ursprünge (Domain, Schema oder Port) als solche zu kennzeichnen, von denen aus ein Browser das Laden von Ressourcen erlauben sollte.

Lass es uns aufschlüsseln.

Frontend-Webanwendung, die in der Regel auf dem Server gehostet wird und mit einer Domain konfiguriert ist, z. B.: xyz.com

• Die Daten werden in der Backend-Datenbank gespeichert und eine API wird bereitgestellt, um auf die Daten aus der Datenbank zuzugreifen. Beachten Sie, dass diese API in einer Domain gehostet ist. abc.com

• Jetzt. abc.com sollte eine bestimmte Anfrage (GET, POST usw.) zulassen, die von xyz.com und Anfragen von anderen Domänen ablehnen

• Auch wenn die Frontend-Anwendung ebenfalls gehostet wird. abc.comDann nimmt die Domain an, dass sie ein Teil davon ist, und wird die Anfrage zulassen, um auf die Ressource zuzugreifen.

Cross-Origin Resource Sharing (CORS) ist ein Mechanismus, der es Webbrowsern ermöglicht, sicher auf Ressourcen von einem Server zuzugreifen, der sich auf einer anderen Domain befindet. Wenn eine Webseite eine Anfrage an einen Server stellt, der sich nicht auf derselben Domain wie die Seite befindet, blockiert der Browser in der Regel die Anfrage, um Cross-Site-Scripting (XSS)-Angriffe zu verhindern. CORS bietet Webentwicklern die Möglichkeit festzulegen, welche Domains berechtigt sind, auf die Ressourcen ihres Servers zuzugreifen und unter welchen Umständen.

Warum wird CORS benötigt?

Früher waren so gut wie alle Anwendungen monolithisch, was bedeutet, dass sowohl die Client- als auch die Serverkommunikation vom selben Ursprung/Domain stammen. Mit dem Aufkommen von Microservices und offenen APIs entsteht die Notwendigkeit, dass der Client auf Ressourcen aus verschiedenen Domänen zugreifen kann oder mit anderen Worten, der Server Anfragen aus verschiedenen Domänen bedient.

CORS stellt sicher, dass die Anwendung ist

1. Gesichert

Das Zulassen von Cross-Origin-Anfragen kann ein Sicherheitsrisiko darstellen, da es Websites ermöglicht, auf Ressourcen von anderen Domains zuzugreifen, die möglicherweise nicht vertrauenswürdig sind. Zum Beispiel kann eine bösartige Website JavaScript verwenden, um Anfragen zum Zugriff auf Ressourcen zu injizieren, die nicht für den Austausch vorgesehen sind.

Die Webanwendung funktioniert ordnungsgemäß.

Alle Browser folgen im Allgemeinen einem Same Origin Policy (SOP) ist eine Sicherheitsrichtlinie, die in Webbrowsern implementiert ist, um zu verhindern, dass ein Skript von einer Website auf Ressourcen einer anderen Website zugreift. Als sicheres Mechanismus zur Kontrolle von Cross-Origin-Anfragefälschungen. Ohne die Einrichtung von CORS wird die Webanwendung nicht ordnungsgemäß funktionieren können, da sie keine Daten von einer API abrufen kann, die auf einer anderen Domain gehostet wird. Durch die Einrichtung von CORS-Regeln können Entwickler der Webseite den Zugriff auf die Ressourcen der API ermöglichen und gleichzeitig verhindern, dass andere Domains unberechtigte Anfragen stellen.

Arten von Browser-Anfragen

Nicht alle Anfragen, die vom Browser erstellt werden, sind gleich, es gibt verschiedene Arten davon.

• Einfache Anfragen:Der einfachste Typ eines CORS-Anforderung ist eine "einfache Anfrage". Diese Anfragen werden mit den HTTP-Methoden GET, HEAD oder POST durchgeführt, und der Content-Type-Header ist auf eine kleine Menge von Werten beschränkt. Damit eine einfache Anfrage erfolgreich ist, muss der Server mit einem Access-Control-Allow-Origin-Header antworten, der ausdrücklich die anfordernde Domain erlaubt.

• Vorab-Anfragen:Wenn eine Anfrage nicht den Kriterien für eine einfache Anfrage entspricht, wird sie als "preflighted request" betrachtet. Preflighted-Anfragen werden mit der OPTIONS-Methode gesendet und enthalten einen zusätzlichen Satz von Headern, die die tatsächliche Anfrage beschreiben, die gestellt werden soll. Der Server muss mit einem Access-Control-Allow-Origin-Header antworten, sowie mit einem Access-Control-Allow-Methods-Header, der die HTTP-Methoden auflistet, die für die angeforderte Ressource erlaubt sind.

Wie konfiguriert man CORS in der API Gateway mit dem Serverless Framework?

In diesem Beispiel arbeiten wir mit einer AWS Lambda, die über das AWS API Gateway als HTTP-API freigegeben ist. Wir werden nicht darauf eingehen, wie man eine Lambda erstellt, sondern uns nur auf die Konfigurationen konzentrieren, die in der serverless.yaml vorgenommen werden müssen, und den Code, der benötigt wird, um die CORS-Anfragen erfolgreich vom Browser verarbeiten zu lassen.

Die serverless.yaml-Einstellungskonfigurationen für eine einfache helloWorld-Funktion lauten wie folgt:

service: corssettings
frameworkVersion: '3.0'
provider:
  name: aws
  runtime: nodejs16.x
functions:
  helloworld:
    name: helloWorld
    handler: src/handlers/helloworld.handler
    events:
      - http:
          method: get
          path: /helloworld
          cors:
            origins:
              - 'https://*.increscotech.com'
              - 'http://localhost:3000'
            headers:
              - accesstoken
            allowCredentials: true

Sobald diese Funktion in der AWS bereitgestellt wird, können wir die Lambda-Funktion sehen, die zusammen mit dem API-Gateway erstellt wurde, wo ein GET-Endpunkt für dieselbe Funktion über das API-Gateway freigegeben wird.

Konfigurationsdetails:

In der obigen Konfiguration,

• EreignisseAbschnitt - enthält die Einstellungen für das HTTP-Ereignis für die Lambda-Funktion. Die Methode: GET gibt an, dass die erlaubten HTTP-Methoden OPTIONS und GET sind. Die OPTIONS-Methode wird standardmäßig erlaubt sein.

• CORS (Cross-Origin Resource Sharing) ist ein Mechanismus, der es Webseiten ermöglicht, Ressourcen von verschiedenen Quellen im Internet abzurufen.Abschnitt - enthält die Einstellungen im Zusammenhang mit der CORS-Kommunikation.

  Ursprünge:
    - 'https://*.increscotech.com'
    - 'http://localhost:3000'

• https://*.increscotech.com - zeigt an, dass der Ursprung der Anfrage von einem der Subdomains von ... increscotech.com

• http://localhost:3000- zeigt nur localhost:3000 Es ist erlaubt mit dem HTTP-Schema.

  Überschriften:
    - Zugriffstoken

  DieZugriffstokenunterÜberschriftenDies deutet darauf hin, dass nur dieser benutzerdefinierte Header in den Anfragen erlaubt ist.

  Die Einstellung allowCredentials:true ermöglicht es dem Server, die Anfragen mit Berechtigungen zu verarbeiten.

All diese Einstellungen werden in der Antwort für eine Preflight-Anfrage verwendet. Jede Abweichung in den Werten, die in den Anforderungsheadern gesendet werden, führt zu einem CORS-Fehler.

Code für Antwortheader:

Da die Lambda-Funktion über einen Lambda-Proxy freigegeben wird, wird die Antwort vom API Gateway als Durchgang weitergeleitet. Daher muss unsere Lambda-Funktion den Wert Access-Control-Allow-Origin zurückgeben, wenn es eine tatsächliche Anfrage gibt. Unser Lambda-Code würde die folgende Logik haben, um dies zu berücksichtigen.

export const handler = async (event) => {
    const requestOrigin = event.headers.origin;
    const response = {
        statusCode: 200,
        headers: {
            "Access-Control-Allow-Headers": "Content-Type",
            "Access-Control-Allow-Origin": getAllowedOrigin(requestOrigin),
            "Access-Control-Allow-Methods": "OPTIONS, GET",
            "Access-Control-Allow-Credential": true,
        },
        body: JSON.stringify('Hello World!'),
    };
    return response;
};

const allowedOrigins = 
['https://*.increscotech.com', 'http://localhost:*'];

const getAllowedOrigin = (requestOrigin) => {
    const [protocol, domain] = requestOrigin.split('://');
    const [hostname, port = ''] = domain.split(':');
    const originForValidation = `${protocol}://${
       hostname === 'localhost' 
       ? hostname 
       :`*.${hostname.substring(hostname.indexOf('.'))}`
    }${port ? `:3000` : ''}`;

    return allowedOrigins.includes(originForValidation) ? requestOrigin : null;
};

Zusammenfassung:

• CORS ist ein Sicherheitsmechanismus, bei dem Anfragen von autorisierten Ursprüngen zugelassen werden und Antworten für dieselben gerendert werden.

• 3 Arten von CORS-Anfragen - einfache Anfragen, vorab genehmigte Anfragen und Anfragen mit Anmeldeinformationen.

• Für eine erfolgreiche Verarbeitung einer CORS-Anfrage müssen die APIs auf der Serverseite mit den Einstellungen für die Antwortheader konfiguriert werden.