Cross-Origin Resource Sharing (CORS), allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods
- Access-Control-Max-Age

The browser generates a preflight OPTIONS request whenever the cross domain request made by the web page is anything other than a simple HTTP request. A GET or POST HTTP request with no special headers or credentials is considered a simple request. A response for a preflight request exposes the server's CORS policy via specialized headers mentioned previously. After examining the required permissions, the browser makes the actual request that the web page initially performed. This extra preflight request adds overhead and hence the server can configure its preflight response to be cached.
Prolonged caching of a preflight response can pose a security threat as the policy can be updated on the server while a browser will still allow unauthorized access to resources based on the original cached policy. The time a response is allowed to be cached is conveyed using an Access-Control-Max-Age response header and a value of more than 30 minutes is considered to be prolonged.

The Access-Control-Allow-Methods header, as reflected in the preflight response for the requested resource, indicates that it allows unsafe HTTP methods. An attacker can use HTTP methods such as PUT or DELETE to make unexpected modifications to a shared resource and pose a security threat to the overall site security. A user agent rejects any request for this resource with an HTTP method other than the ones that are listed in the Access-Control-Allow-Methods response header.
Cross-Origin Resource Sharing (CORS), allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods

Content Security Policy (CSP) is an HTTP response security header that developers can leverage to specify external domains from which the site is allowed to load resources such as images and JavaScript files. This header provides in-depth security protection from critical vulnerabilities such as cross-site scripting (XSS) and clickjacking. Before Content-Security-Policy was standardized under the current header, two different experimental equivalents of this header existed: X-Content-Security-Policy and X-WebKit-CSP. The X-Content-Security-Policy was implemented and maintained in Firefox until version 23 and in Internet Explorer until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Some browsers might still accept the header, but modern browsers no longer maintain, support, or enhance implementation of these two experimental versions.

HTTP headers are key-value pairs sent between the client and server to provide additional information for handling HTTP requests and responses. Browser vendors mark some HTTP headers as deprecated when they no longer maintain, support, or enhance implementation of the header. Usage of these headers might create a false sense of security and increase the site's vulnerability.

Developers should rely on HTTP headers specified in the HTML standard[3] as they are supported uniformly across browsers. Using non-standard headers might provide additional features and controls but comes with limited browser support and risk of deprecation.

For example, the X-XSS-Protection header was used by developers to control the browser's behavior and offer protection against cross-site scripting (XSS). Modern browsers have better built-in protections with the use of Content Security Policy. Therefore, relying on X-XSS-Protection header can introduce new risks.

One of the features of HTML5 is the ability to store data in a client-side SQL database. The main piece of information required to start writing to and reading from the database is its name. Therefore, it is crucial that the name of the database is a unique string that differs from user to user. If the name of the database is easy to guess, unauthorized parties, such as other users, might be able to steal sensitive data or corrupt the database entries.
Example 1: The following code uses an easy-to-guess database name:

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

This code will run successfully, but anyone who can guess the database name to be 'mydb' can access it.

Content Security Policy (CSP) is a declarative security header that allows developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of fifteen directives including eight that control resource access, namely: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Each of these takes a source list as a value specifying domains the site is allowed to access for a feature covered by that directive. Developers may use wildcard * to indicate all or part of the source. None of the directives are mandatory. Browsers will either allow all sources for an unlisted directive or will derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of the names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer might misconfigure this header.

Consider the following misconfiguration scenarios:

- Directives with unsafe-inline or unsafe-eval defeats the purpose of CSP.
- script-src directive is set but no script nonce is configured.
- frame-src is set but no sandbox is configured.
- Multiple instances of this header are allowed in same response. A development team and security team might both set a header but one may use one of the deprecated names. While deprecated headers are honored if a header with the latest name (that is, Content Security Policy) is not present, they are ignored if a policy with content-security-header name is present. Older versions only understand deprecated names, hence, in order to achieve desired support it is essential that the response include an identical policy with all three names.
- If a directive is repeated within the same instance of the header, all subsequent occurrences are ignored.

Example 1: The following django-csp configuration uses unsafe-inline and unsafe-eval insecure directives to allow inline scripts and code evaluation:

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

Content Security Policy (CSP) is a declarative security header that enables developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code.

Spring Security and other frameworks do not add Content Security Policy headers by default. The web application author must declare the security policy/policies to enforce or monitor for the protected resources to benefit from this additional layer of security.

Allowing your website to be added to a frame can be a security issue. For example, it may lead to clickjacking vulnerabilities or allow undesired cross-frame communications.

By default, frameworks such as Spring Security include the X-Frame-Options header to instruct the browser whether the application should be framed. Disabling or not setting this header can lead to cross-frame related vulnerabilities.

Example 1: The following code configures a Spring Security protected application to disable the X-Frame-Options header:

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>

Content Security Policy (CSP) is a declarative security header that enables developers to specify allowed security-related behavior within the browser, including an allow list of locations from which content can be retrieved. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of 15 directives including 8 that control resource access: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. These 8 directives take a source list as a value that specifies domains the site is allowed to access for a feature covered by that directive. Developers can use a wildcard * to indicate all or part of the source. Additional source list keywords such as 'unsafe-inline' and 'unsafe-eval' provide more granular control over script execution but are potentially harmful. None of the directives are mandatory. Browsers either allow all sources for an unlisted directive or derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of these names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer can misconfigure this header.

Example 1: The following code sets an overly permissive and insecure default-src directive:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, exercise caution when defining the header because an overly permissive CORS policy can enable a malicious application to inappropriately communicate with the victim application, which can lead to spoofing, data theft, relay, and other attacks.

Example 1: The following is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Using the * as the value of the Access-Control-Allow-Origin header indicates that the application's data is accessible to JavaScript running on any domain.

One of the new features of HTML5 is cross-document messaging. The feature allows scripts to post messages to other windows. The corresponding API allows the user to specify the origin of the target window. However, caution should be taken when specifying the target origin because an overly permissive target origin will allow a malicious script to communicate with the victim window in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following example uses a wildcard to programmatically specify the target origin of the message to be sent.

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

Using the * as the value of the target origin indicates that the script is sending a message to a window regardless of its origin.

Browsers do not send the referrer header by default with requests originated from HTTPS to unencrypted HTTP links. However, when a request destination is also HTTPS, the header is sent regardless of the origin. A developer might leave sensitive information in URLs, which are exposed to third-party sites via the referrer header. The Referrer-Policy header is introduced to control browser behavior related to the referrer header. The Unsafe-URL option removes all restrictions and sends the referrer header with every request.

Example 1: The following code configures a Spring Security protected application to disable the default secure the referrer policy:

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

Content Security Policy (CSP) is a declarative security header that enables developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code.

The Content-Security-Policy-Report-Only header provides the capability for web application authors and administrators to monitor security policies, rather than enforce them. This header is typically used when experimenting and/or developing security policies for a site. When a policy is deemed effective, you can be enforce it by using the Content-Security-Policy header field instead.

Example 1: The following code sets a Content Security Policy in Report-Only mode:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emojis and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a keylogger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.

The extension receives data from the host app in its view controller and fails to implement the SLComposeServiceViewController isContentValid to validate the untrusted data received before using it.

Example 1: The following extension view controller receives data from the host app but fails to implement a callback method to validate it:

    #import <MobileCoreServices/MobileCoreServices.h>

    @interface ShareViewController : SLComposeServiceViewController
        ...
    @end

    @interface ShareViewController ()
        ...
    @end

    @implementation ShareViewController

    - (void)didSelectPost {
        NSExtensionItem *item = self.extensionContext.inputItems.firstObject;
        NSItemProvider *itemProvider = item.attachments.firstObject;
        ...
        // Use the received items
        ...
        [self.extensionContext completeRequestReturningItems:@[] completionHandler:nil];
    }

    ...

    @end

When a third party application or webview uses a URL to communicate with your application, the receiving application should verify that the sender matches an allow list of applications that are expected to communicate with it. The receiving application has the option to verify the origin of the calling URL using the UIApplicationDelegate application:openURL:options: or UIApplicationDelegate application:openURL:sourceApplication:annotation: delegate methods.

Example 1: The following implementation of the UIApplicationDelegate application:openURL:options: delegate method fails to verify the sender of the IPC call and just processes the calling URL:

    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options {
        NSString *theQuery = [[url query] stringByRemovingPercentEncoding:NSUTF8StringEncoding];
        NSArray *chunks = [theQuery componentsSeparatedByString:@"&"];
        for (NSString* chunk in chunks) {
            NSArray *keyval = [chunk componentsSeparatedByString:@"="]; NSString *key = [keyval objectAtIndex:0];
            NSString *value = [keyval objectAtIndex:1];
            // Do something with your key and value
        }
        return YES;
    }

When a third party application or webview uses a URL to communicate with your application, the receiving application should validate the calling URL before proceeding with further actions. The receiving application has the option to verify that it wants to open the calling URL using the UIApplicationDelegate application:didFinishLaunchingWithOptions: or UIApplicationDelegate application:willFinishLaunchingWithOptions: delegate methods.

Example 1: The following implementation of the UIApplicationDelegate application:didFinishLaunchingWithOptions: delegate method fails to validate the calling URL and always processes the untrusted URL:

    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NS Dictionary *)launchOptions {
        return YES;
    }

Applications may register custom URL schemes for third party applications to communicate with them. Although this is a simple IPC channel, it may expose your application to "URL Scheme Hijacking". Since any application can register a URL scheme as long as it is not reserved by Apple, a malicious application may register the same scheme used by your application which results in an undefined behavior. According to Apple's documentation: "If more than one third party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme". If the malicious application is installed before your application, it may register the scheme and prevent your application from installing successfully. Alternatively, if the malicious application is installed after your application and it succeeds in the scheme registration, it may hijack it from your application.

Android's backup service allows the application to save persistent data to a remote cloud storage in order to provide a restore point for the application data in the future.

Android applications can be configured with this backup service by setting the allowBackup attribute to true (the default value) and defining the backupAgent attribute on the <application> tag.

Android however, does not guarantee the security of your data while using backup, as the cloud storage and transport vary from device to device.

Files saved to the external storage are world-readable and can be modified by the user when they enable USB mass storage to transfer files on a computer. Also, files on the external storage card will remain there even after the application that wrote the files is uninstalled. These limitations can compromise sensitive information written out to storage or allow attackers to inject malicious data into the program by modifying an external file it relies on.

Example 1: In the following code, Environment.getExternalStorageDirectory() returns a reference to the Android device's external storage.

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }