CORS header missing on HTTP 201 response

I’m calling the Dwolla API from client-side javascript. When adding a funding source to a customer I’m getting HTTP 201 with a valid location header, but the browser is blocking the response because the Dwolla API isn’t provided the Access-Control-Allow-Origin header. Here are the relevant error logs from the browser console:

Access to XMLHttpRequest at ‘https://api-sandbox.dwolla.com/customers/472bf6dd-0e8f-407b-acfc-5255b0b639a7/funding-sources’ from origin ‘http://localhost:8082’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
xhrio.js:631
POST https://api-sandbox.dwolla.com/customers/472bf6dd-0e8f-407b-acfc-5255b0b639a7/funding-sources net::ERR_FAILED 201

Curiously, when I send an unauthenticated request (or any other kind of failure, like a DuplicateResource) to that same endpoint I actually do get the expected CORS header. Why doesn’t the HTTP 201 Created response return the CORS header? Is there anything I can do on my end to resolve this?

I’m using Chrome 97.0.4692.99 on macOS 12.1

As you can see in this screenshot, the Dwolla API response doesn’t contain the Access-Control-Allow-Origin header:

Here’s the payload I was sending:

{"routingNumber":"111000038","accountNumber":"123412341234","bankAccountType":"checking","name":"First Account"}

Hi @mikewhat , Dwolla’s API blocks CORS requests for security purposes. Referenced in this thread: Dwolla.post giving me a CORS error - #2 by shreya

I’d recommend either moving these calls to your back-end server or utilize our drop-in components library which is allows you to utilize pre-built UI components to make isolated calls to Dwolla.

Thanks for the quick reply! Couple follow-up questions:

Aren’t CORS headers in place to help enforce and preserve the security of cross-origin requests?

The CORS mechanism supports secure cross-origin requests and data transfers between browsers and servers. Modern browsers use CORS in APIs such as XMLHttpRequest or Fetch to mitigate the risks of cross-origin HTTP requests. (Cross-Origin Resource Sharing (CORS) - HTTP | MDN)

I was under the impression that we could use a server-side call to get an OAuth access token which our client-side code could then use to push the customer and bank info straight to Dwolla. Is this not what your drop-in UI would have to do? Your front-end, drop-in code would have to make cross-origin requests from our origin to Dwolla’s, right?

We’d prefer to avoid the liability of proxying the customer info and bank info via our back-end server, where that sensitive information might appear in server logs, etc… We’d also like to have complete control over the UI experience for our customers so we’d like to avoid the drop-in components.

The primary difference between making requests to Dwolla directly via our API vs. the drop-in components library would be the scopes/permissions contained on the access token that authenticates the request. Requests made from the drop-ins library (dwolla-web.js) require a granular scoped client-token. Making a request to: https://api.dwolla.com/token would generate a token with broad level access to all functions in the Dwolla API. If someone were to obtain that token, they could turn around and perform actions such as transferring funds, viewing customer info, etc.

yep, this is correct!

Customer data and bank data can be submitted to Dwolla client-side using the dwolla-web.js library and allow for a wide latitude of control over the UI through passing in a custom stylesheet. Another option would be to utilize another service like Basis Theory which tokenizes that sensitive data. Albeit, this would be adding another tool to the chain of tools you may already have.

Ah, I didn’t know about the different kinds of tokens–that’s very helpful!

So, our client should ask our server to request a “funding source token” from Dwolla: Add Bank - Create Funding Source Token | Dwolla API Documentation

Then, your guide recommends using the dwolla.js SDK to make the calls using the newly acquired “funding source token” (Add Bank - Configure and Call Dwolla.js | Dwolla API Documentation).

Now for the real question: Is there anything wrong with us issuing those HTTP calls ourselves instead of deferring to your dwolla.js SDK? (Does the SDK issue different calls than those described in your API documentation?) @spencer

Here’s the full workflow as it currently stands:

  1. client asks server to create customer
  2. server gets an access token from dwolla API
  3. server creates customer in dwolla system by calling dwolla API with the access token
  4. server returns newly created customer id back to client
  5. client provides customer id to server, requesting a funding-sources-token.
  6. server requests a funding-sources-token for that customer from the dwolla api.
  7. server returns that token back to the client
  8. client sends a dwolla api request to create/attach a funding source to that customer using the recently generated funding-sources-token.
  9. dwolla API responds with HTTP 404 (see attached screenshot).

Does this workflow seem correct? Why would the request to create a funding-sources-token succeed (#6) but the request to attach a funding source fail to find the resource/customer (#9)?

@spencer

Hi @mikewhat – your workflow looks correct up to step 7. In steps 8 and 9, instead of using the newly created funding-sources-token as an access token to call the API for creating a funding-source, you will need to pass the token to the function in dwolla.js and let the library handle the creation of the funding-source with the information collected via the form. This allows you to not handle the PII of the user, and not have to work validating each of the form-field, while still giving you flexibility to style the UI and UX of the bank addition process.

To answer this question, yes the dwolla.js library does make different calls than the one in the API reference to create a funding-source. Although technically it may be possible to make the specific calls directly from your client-side, we don’t advise this in practice. The library offers an abstraction on top of our API to route these requests which provides a layer of flexibility, since any of the implementation details may be subject to change (request URL, permissions, version, etc.). We recommend utilizing the library for passing on information to the API.

Thanks @shreya for your answers. As far as the handling of PII is concerned, I struggle to see the difference between doing a direct API call and calling dwolla.js (which then does a direct API call). In both cases, our client-side code has to ‘handle’ the PII for a split second (in memory on the end-user’s device) to hand it off to Dwolla. Nor do I see why dwolla.js should do different/unlisted api calls. Why not ‘eat your own dogfood’?

But I’ll give dwolla.js a try…

The call to dwolla.js is working now, thanks for helping me work through this @shreya and @spencer

1 Like