Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers to restrict how resources on a web server can be requested from another domain. A key aspect of CORS is the Access-Control-Allow-Origin header, which specifies which domains are allowed to access the resources.
In the observed configuration, the header was set to *, indicating that the resources can be accessed by any domain. While this setting facilitates access, it significantly reduces security by potentially allowing malicious sites to make requests to the server and access its responses, which may contain sensitive information.
For mobile apps, CORS becomes most relevant when WebViews are used to display web content. WebViews behave similarly to browsers and therefore respect CORS policies. It's important to note that native app components that communicate directly with APIs are not subject to CORS because it's a browser-enforced protocol, not network or OS-level enforcement.
When integrating WebViews into mobile apps, developers must carefully consider the impact of CORS settings. Using a permissive configuration such as Access-Control-Allow-Origin: * can inadvertently expose your app to security vulnerabilities, especially if the WebView processes content from or interacts with untrusted sources.
Steps to Reproduce
As the app is being exercised on a physical device, each network call is observed. Within those network calls, The header Access-Control-Allow-Origin is checked to ensure that it is not set to *. If it is, then this will flag as an issue.
Business Impact
A resource the app communicates with is not using a best practice which can help prevent sensitive data from being intercepted.
Remediation Resources
The reported endpoints should be carefully reviewed to determine their interaction with any WebViews within the app, particularly in regard to the handling of sensitive information.
For backend resources under your control, it's advisable to configure the Access-Control-Allow-Origin header to enumerate explicitly allowed domains, rather than adopting an open policy with *. This approach minimizes exposure to potential cross-origin attacks by restricting access to trusted domains only, enhancing the overall security posture of both the app and its backend infrastructure.
Note that this scenario often involves APIs operated by third-party services, leaving the app development team with the task of acknowledging and actively managing the associated risks. This includes assessing the risks, understanding the data exchanged with these services, and implementing mitigation strategies or securing data security agreements with these providers.
Finding Description
Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers to restrict how resources on a web server can be requested from another domain. A key aspect of CORS is the
Access-Control-Allow-Originheader, which specifies which domains are allowed to access the resources.In the observed configuration, the header was set to
*, indicating that the resources can be accessed by any domain. While this setting facilitates access, it significantly reduces security by potentially allowing malicious sites to make requests to the server and access its responses, which may contain sensitive information.For mobile apps, CORS becomes most relevant when WebViews are used to display web content. WebViews behave similarly to browsers and therefore respect CORS policies. It's important to note that native app components that communicate directly with APIs are not subject to CORS because it's a browser-enforced protocol, not network or OS-level enforcement.
When integrating WebViews into mobile apps, developers must carefully consider the impact of CORS settings. Using a permissive configuration such as
Access-Control-Allow-Origin: *can inadvertently expose your app to security vulnerabilities, especially if the WebView processes content from or interacts with untrusted sources.Steps to Reproduce
As the app is being exercised on a physical device, each network call is observed. Within those network calls, The header
Access-Control-Allow-Originis checked to ensure that it is not set to*. If it is, then this will flag as an issue.Business Impact
A resource the app communicates with is not using a best practice which can help prevent sensitive data from being intercepted.
Remediation Resources
The reported endpoints should be carefully reviewed to determine their interaction with any WebViews within the app, particularly in regard to the handling of sensitive information.
For backend resources under your control, it's advisable to configure the
Access-Control-Allow-Originheader to enumerate explicitly allowed domains, rather than adopting an open policy with*. This approach minimizes exposure to potential cross-origin attacks by restricting access to trusted domains only, enhancing the overall security posture of both the app and its backend infrastructure.Note that this scenario often involves APIs operated by third-party services, leaving the app development team with the task of acknowledging and actively managing the associated risks. This includes assessing the risks, understanding the data exchanged with these services, and implementing mitigation strategies or securing data security agreements with these providers.
Risk and Regulatory Information
Severity: info
Policy Category: Informational
Application
See more detail in the NowSecure Report
Evidence
| Vulnerable Connections | |---| | https://access.active911.com/interface/ios_api_1.4.php | | https://access.active911.com/interface/ios_api_1.4.php | | https://access.active911.com/interface/ios_api_1.4.php | ... and 3 more