CORS headers: my app doesn't work after update

CORS headers: my app doesn't work after update

edited 07/21/2019 - 15:01 in SoundTouch API
LenkradLenkrad Posts: 2Member
Hi, after the last upgrade I downloaded for my SoundTouch 20 a few weeks ago something seems to have changed with CORS headers.
My very simple web control interface is not able to get volume any more, and when sending a key press I also get an error.

My device is at 192.168.232.120 and the web app at 192.168.232.126 ("nashorn").
The response contains the following header:
Access-Control-Allow-Origin: http://192.168.232.120
And so chrome blocks me from seeing the response. But when sending a POST the request is handled, I just am not allowed to see the result. Error message in chrome console:
Access to XMLHttpRequest at 'http://192.168.232.120:8090/presets' from origin 'http://nashorn' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'http://192.168.232.120' that is not equal to the supplied origin.

My question: did you change anything about the CORS headers in the last update, and would it be possible to revert that? I really don't see why it should not be possible to control the device from another network. And if there is a reason for that it shouldn't be possible to send POST as well.
It would be good to be at least able to allow cross origin requests in the SoundTouch settings.

Alternatively I have to write a backend service just for forwarding simple requests to another device in the same network, and I think that does not make much sense.

Thanks,
Lennart

Comments

  • kdw2060kdw2060 Posts: 13Member
    +1 facing the same issue, my local network app that i made doesn't work anymore either
  • Zach@Bose[email protected] Posts: 160Admin

    Hi @Lenkrad and @kdw2060

    Apologies for the lengthly delay in response. I’ve confirmed with our security team that we have in fact introduced a new CORS policy to the SoundTouch API in a recent firmware update. This is not something we plan to roll back at this time.

    The CORS policy should apply equally to all API calls, which we’ve reconfirmed in our internal testing, so if @Lenkrad you are still seeing the new policy not applied to POST commands as it sounds like you suggested, we may be interested in getting some additional information from you to help us investigate, if you are willing to share. You can let me know via DM if this is the case.

    Alternatively, if you believe there is a vulnerability related to this, you could report it via our security vulnerability response process, which is documented here: https://www.bose.com/security. We always encourage users to submit any concerns they have regarding the security of our products or services to Bose following the guidelines on that page.

    We didn’t intend to roll this new policy out without announcing – that was a communication misstep on our end; we’ll aim to do better in that regard next time.

    -Zach

  • kdw2060kdw2060 Posts: 13Member
    What I found was that the /speaker POST call still works clientside when the url in the payload is a regular website url. You get an error, but the call is still executed and the speaker plays the provided soundfile.
    When the url is a local ip-address the call only works when executed from the server. (didn't test with non-local ip's)
Sign In or Register to comment.