When a flash application is embedded within HTML, there are several flags which inform the Flash player if the SWF file should have access to content from the browser or from the network.
- AllowScriptAccess
This flag tells the Flash player to allow the SWF to communicate with the browser and HTML DOM using ExternalInterface, fscommand or getURL.
- AllowNetworkingAccess
This flag informs the Flash player that it is allowed to make networking calls like XML.load, loadVariables, LoadVars.load etc. If a Flash application should not communicate with the browser or need to make any networking calls the AllowNetworkingAccess tag should be set to "none".
1. If a Flash application should not communicate with the browser or need to make any networking calls the AllowNetworkingAccess tag should be set to "none".
2. If a Flash application should not communicate with the browser but does need to make networking calls the AllowNetworkingAccess tag should be set to "internal".
3. If a Flash application needs to communicate with both the browser and the network, the AllowNetworkingAccess tag should be set to "all".

It has become important to enforce the data privacy of a given web document due to the existance of side-channel exploits that result from vulnerabilities such as Spectre and Meltdown. The Cross-Origin Opener Policy (COOP) was created to help prevent sensitive information exposure due to side-channel attacks. Specifically, the COOP can enforce isolation of a document's browsing context group in regard to other external documents, such as popups.

Example 1: The following code shows an unsecure COOP setting of 'unsafe-none' in the Django framework. This might allow an external document to access the private data of a source document's browsing context group due to a side-channel attack.

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that 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 above. 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 more than 30 minutes is considered to be prolonged.

SAML messages are cryptographically signed to guarantee validity and integrity of the assertion. Man in the middle attackers can tamper with the SAML Response message without signatures. The attacker can modify the permissions and user for the service provider and gain access to the application.

SAP system provides for extensive authorization configuration and access management. System level configuration is also available to restrict permissions based on the system role. Together, these features make user or system dependent programming irrelevant. That is, there cannot be a scenario in a securely configured customer productive system where functionality of a program is dependent on the user executing the program or the system on which the program is being executed. Querying user or system details to influence program flow is therefore a bad practice and can indicate the presence of a possible backdoor.

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example Ansible task defines a wildcard lambda principal.

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present

AWS API Gateway methods that are publicly accessible can expose the organization to attack.

Example 1: The following example template defines publicly accessible AWS API Gateway methods.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "MyMethod0": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "GET",
                "AuthorizationType": "NONE"
            }
        },
        "MyMethod1": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "POST",
                "AuthorizationType": "NONE",
                "ApiKeyRequired": false
            }
        }
    }
}