Do you see anything different in the headers between the two environments?

Are you sure the code is the same in both places?

Does there happen to be a WAF in production? If yes, are there any security policies/rules that might be getting in the way?

In the Response Headers Section I found the following difference:

Production (not working) > There is one entry which is only in the online Request available:
WWW-Authenticate: Basic realm="www.xxxxxxx.ch"

Does the domain match what you expect? 

Yes, it does

Okay, interesting...  

What about the firewall question?  Do you have anything like that getting in the way too, or no?  

The next test I would perform after that, would be to backup the website, and restore it as a test site on the same server, as a Staging site.  This would also allow you to do further testing to see if it's the website itself or something else in your infrastructure.  For example, toggling debugging and whatnot.  

Once you have the staging website up and running, turn on debugging in the website config file, in DNN itself (Host Settings), and in Log4NET to gather even more information.  When do all of them, you'll have all possible logging turned on.  Also, the URL provider may insert more/new/different details into the response headers.  

If you want to save some steps in turning on all of the debugging, you can use our Upendo DNN Prompt command to do that.  

• Download:  https://github.com/Upendo...-Dnn-Prompt/releases
• Documentation:  https://github.com/Upendo...rompt/wiki/set-debug

...and look for differences in your IIS configurations

No WAF in use.

Enabled all debugging possibilities, I found  the following warning in Log-File:
------------
2023-07-26 19:05:26,448 [ranger][Thread:109][WARN] DotNetNuke.Entities.Tabs.TabController - Invalid tabId -1 of portal 0

2023-07-26 19:05:26,448 [ranger][Thread:109][WARN] DotNetNuke.Web.Api.StandardTabAndModuleInfoProvider - The specified moniker () is not defined in the system
------------

BTW: Code is the following

public class ExchangeOrderController : DnnApiController
    {
        [HttpGet]
        [DnnAuthorize(StaticRoles = "ExchangeOrderDK")]
        public IHttpActionResult Get()
        {
            try
            {
                return Ok("Request was successful!");
            }
            catch (Exception ex)
            {
                return Content(HttpStatusCode.InternalServerError, ex.Message);
            }
        }
    }

One thing that is very strange: My ISP told me that he can authorize successfully to my API with the FTP-Credentials (which have nothing to do with the users and roles inside DNN)