CORS header incorrect

[tcdevs]

I have the same problem as @heycait on issue #370.

Im using the url https://api.sendgrid.com/api/mail.send.json with my custom AngularJS factory to send an email. This will work but i still get a CORS error. It will send the email accordingly.

This are the custom settings for the header in the AngularJS $http service:

headers: {
    'Content-Type': 'application/json' , 
    'Access-Control-Allow-Origin': 'http://sendgrid.com',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
    'Access-Control-Allow-Headers':'X-Requested-With'   
}

or with wildcard

headers: {
    'Content-Type': 'application/json' , 
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
    'Access-Control-Allow-Headers':'X-Requested-With'   
}

With both of the example headers i get the following error message:

Response to preflight request doesn't pass access control check: 
The 'Access-Control-Allow-Origin' header has a value 'https://sendgrid.com' 
that is not equal to the supplied origin. Origin 'http://192.168.0.25:8031' is 
therefore not allowed access.

The problem seems to be the 'Access-Control-Allow-Origin ' header on your domain need to be an wildcard instead of 'http://sendgrid.com'

Can this problem be fixed? Thanks for the help in advance.

[mbernier]

yes, we are working on this now with our OPs team.

[cupcakedream]

Hey has this been fixed yet? I'm running into CORS issues with the API

[scottmahr]

Also waiting on this. Is there a good work around?

[Jimmathy]

I think I'm having the same issue with my Laravel API...

$emailUser = array();
$emailUser['email'] = $request->email;
$emailUser['first_name'] = $request->first_name;
$emailUser['last_name'] = $request->last_name;

    Mail::send('email.registered_user', $emailUser, function($message) use ($emailUser)
    {   $message->to($emailUser['email'], $emailUser['first_name'] . ' ' . $emailUser['last_name']);
        $message->from('WSCUSTOMERPO@waterstoneco.com', 'Waterstone Faucets');
        $message->replyTo('WSCUSTOMERPO@waterstoneco.com', 'Waterstone Faucets');
        $message->subject("Welcome to the Waterstone Faucets Portal!");
    });

Would this fall under the same issue though?

[mbernier]

Hey guys, we're not ignoring you. I am working through this issue, checking with my teams to figure out what's going on. I do need some extra information if you can provide it.

@Jimmathy are you getting a specific error? can you please provide it?

@bstaruk if that tool is making the call from the browser, the CORS rejection is likely legitimate as a browser to API call is potential security concern for the user. We will ask customers not to make JS calls to the API from their front end website, but rather to make an AJAX call to a server side script, as the browser request to SendGrid means there is likely an exposed API KEY in the mix.

[ZetIsDeadBaby]

+1
same issue, PHP Slim API with AngularJS front end

[tcdevs]

@mbernier any news yet?

[UCJava]

Hi Guys,
The issue is "Access-Control-Allow-Origin" header needs to be exposed and set to "*" on the https://api.sendgrid.com/api/mail.send.json API response . Are you still trying to figure out how to change the response ? or is this on the way to be fixed ? This will allow people to use JS libraries directly from browsers , the request seems to go through but the response is not getting acccepted due to CORS. Also I couldn't get the AJAX call with the Authorization header being the API Key bearer token work as well. Is there an issue with that as well ?

[abernix]

Ran into this today while adding support for SG as their competitor is changing their pricing options a bit. I'm using this in a browser extension that (safely) stores the users individual credentials. Of course it's SG's prerogative to set the Allow-Control-Allow-Origin as they want, it's definitely a bit different than what I expect out of a public API (see, I dunno, Github API for example).

Additionally, strange that the API doesn't respond properly to OPTIONS requests. Also, requires authorization token and to address to be set? It appears to be implemented identically to POST and not work as expected for a REST API.

The (not mentioned) competitor used the following CORS rules, allowing this to work from a browser extension.

Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *

SendGrid is currently using only Access-Control-Allow-Origin: https://sendgrid.com

[derekrliang]

Experiencing same issue as well... trying to use V3 with API key on Angular.

[levivm]

I have the same issue using V3 API.

[ZetIsDeadBaby]

after over 6 months still not fixed, so here is solution:

• Amazon SES
• Postmark
• SocketLabs
• MailJet
• ElasticEmail

[mbernier]

There are a couple reasons why we have this functionality the way we have it:

1. We do not want to open up any users or ourselves to the types of interference that this header was designed to prevent.
2. It is not a good idea to have email sending built into a front-end / browser app, because it is likely that your keys, being sent to the API by the customer's browser means your key is your customer's key. That's not great because someone can start sending all kinds of emails through your account once they have your keys.

Having said that, we completely understand that tools like Postman, Stoplight, and others are browser based tools that serve a very specific and useful purpose. We use them too!! So, we completely understand the frustration that comes when something doesn't "just work."

As you know, there is always a balance between security and usability, often times we can find a nice way to make them both win. CORS functionality being a limiting factor for usability on our API is something that I personally have been negotiating and advocating about well before this ticket was opened.

Having said all of that, I brought this back around with both my Infosec and Ops teams to figure out what their official stance is going to be. They told me that they have a solution and I hope to have the official answer and the updates in place very soon (not another 6 months).

[jrsteele23]

I understand how awesome it is to be able to send emails from a front-end Angular application and the client browser but setting 'Access-Control-Allow-Origin' to * seems a bit extreme. While I sure many of the developers above requesting the change understand the security implications many developers do not.

I'm hoping the solution they are working on is a custom [sub]domain per customer that send the 'Access-Control-Allow-Origin' set to a setting that each customer can customize (in their SendGrid account setup). I think a solution like this would be a good balance between security concerns and functionality.

[UCJava]

While the security issue is well known to everyone, there are many secure
REST services out there for similar service. The way web technology has
revolved now it is more than a necessity. Front End frameworks are widely
used, not all websites require a back end server; isn't it extreme to have
a server running for just communicating with a mail provider service ?

On Thu, May 12, 2016 at 8:55 AM, Justin Steele notifications@github.com
wrote:

I understand how awesome it is to be able to send emails from a front-end
Angular application and the client browser but setting
'Access-Control-Allow-Origin' to * seems a bit extreme. While I sure many
of the developers above requesting the change understand the security
implications many developers do not.

I'm hoping the solution they are working on is a custom [sub]domain per
customer that send the 'Access-Control-Allow-Origin' set to a setting that
each customer can customize (in their SendGrid account setup). I think a
solution like this would be a good balance between security concerns and
functionality.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1417 (comment)