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 Member Posts: 2
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 and the web app at ("nashorn").
The response contains the following header:
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 '' from origin 'http://nashorn' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value '' 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.



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

    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: 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.


  • kdw2060kdw2060 Member Posts: 13
    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.