Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code sets the SameSite attribute to None for session cookies.

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appends the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originating from third-party sites, including those that have either iframe or href tags that link to the host site. For example, suppose there is a third-party site that has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
     ...
     .sameSite("None") 
     ...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appends the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originating from third-party sites, including those that have either iframe or href tags that link to the host site. For example, suppose there is a third-party site that has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute limits the scope of the cookie such that it will only be attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.

Example 1: The following code disables the SameSite attribute for session cookies.

ini_set("session.cookie_samesite", "None");

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The samesite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The samesite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

  response.set_cookie("cookie", value="samesite-none", samesite=None)

The SameSite attribute protects cookies from Cross-Site Request Forgery (CSRF) attacks. The browser automatically appends cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data like session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.
The SameSite attribute on a cookie allows sites to control that behaviour and prevents browsers from appending the cookie to request if the request is generated from a third-party site page load. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top level navigation.
- Lax: When set to Lax, cookies are sent with top level navigation from the same host as well as GET requests originated to the host from third-party sites (for example, in iframe, link, href, and so on and the form tag with GET method only).
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.
Cookies that have the SameSite attribute with the value of None must be set with the Secure attribute otherwise the browser rejects the cookies. Additionally, a few specific browser versions reject the SameSite cookie with the None value for example, Chrome versions 51 to 66, versions of the UC Browser on Android prior to version 12.13.2, versions of Safari and embedded browsers on macOS 10.14, and all browsers on iOS 12 reject cookies set with SameSite=None. A suggested workaround for this issue is to set an alternate cookie with a prefix or suffix such as Legacy appended to cookiename. Sites can look for this legacy cookie if it does not find a cookie that was set with SameSite=None.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, attackers can perform a "Cookie poisoning attack" by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from Secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".example.com");

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a "Cookie poisoning attack" by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum. For example:

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a forum user clicks this link, the browser sends the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, attackers can perform a "Cookie poisoning attack" by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  cookie_options = {};
  cookie_options.path = '/';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("sessionid", value)   # Path defaults to "/"
  return res
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a "Cookie poisoning attack" by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code sets the SameSite parameter to Lax for session cookies.

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set session cookies with SameSiteStrictMode for the SameSite attribute, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code enables SameSiteLaxMode in the SameSite attribute for session cookies.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-lax",
  SameSite: http.SameSiteLaxMode,
}

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set the value of the SameSite attribute to Strict in session cookies. This restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code sets the value of the SameSite attribute to Lax for session cookies.

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue") 
     ...
     .sameSite("Lax")  
     ...
}

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set the value of the SameSite attribute to Strict in session cookies. This restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code sets the value of the SameSite attribute to Lax for session cookies.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: "Lax" });
    ...
}

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set session cookies with Strict for the SameSite attribute, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code enables the Lax mode in the SameSite attribute for session cookies.

ini_set("session.cookie_samesite", "Lax");

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker lures an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie with user authorization. This effectively gives the attacker access with the user's authorization.
Set session cookies to Strict for the SameSite parameter, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code enables Lax in the samesite attribute for session cookies.

  response.set_cookie("cookie", value="samesite-lax", samesite="Lax")

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so they can perform authorized actions. However, the browser automatically sends the cookies and therefore user and web sites put an implicit trust on the browser for authorization. An attacker can misuse this trust and make a requests to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. With this, an attacker can trick an unsuspecting user to load this third-party site page in the browser while the user still has authorization to the site that the attacker intends to exploit.
Set session cookies with the Strict value for the SameSite attribute, which restricts the browser to append cookies only to requests that are either top level navigation or originate from the same site. Requests that originate from third-party site via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.

Example 1: The following code sets a cookie to expire in 10 years.

...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

	Cookie cookie = new Cookie("emailCookie", email);
	cookie.setMaxAge(60*60*24*365*10);

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and device restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

    ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Most web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

setcookie("emailCookie", $email, time()+60*60*24*365*10);

Most web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email, expires=time()+60*60*24*365*10, secure=True, httponly=True)
  return res
...

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and device restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true,
    NSHTTPCookieExpires : NSDate(timeIntervalSinceNow: (60*60*24*365*10))
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.

Example 1: The following configuration entry turns off the Secure flag for session cookies.

server.servlet.session.cookie.secure=false

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data, session identifiers, or carries a CSRF token.
Example 1: The following configuration entry does not explicitly set the Secure bit for session cookies.

...
MIDDLEWARE = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of Inter-Component Communication XSS, the untrusted source is data received from other components that reside on the same system. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.

2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.


Example 1: The following Go code segment reads a user name, user, from an HTTP request and displays it to the user.

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

The code in this example operates correctly if user contains only standard alphanumeric text. If user has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

Example 2: The following Go code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

As in Example 1, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack affects multiple users. XSS began in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As shown in Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- As shown in Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker can perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web or mobile application through an untrusted source. In the case of Inter-Component Communication XSS, the untrusted source is data received from other components that reside on the same system. In the mobile world, these are applications running on the same device. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 1: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

If the value of url starts with javascript:, JavaScript code that follows executes within the context of the web page inside WebView.

Example 2: The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

Example 3: The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

As in Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Example 1, a source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

- As in Example 2, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- As in Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

A number of modern web frameworks provide mechanisms to perform user input validation (including Struts and Struts 2). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of Inter-Component Communication XSS, the untrusted source is data received from other components that reside on the same system. In the mobile environment, these are applications running on the same device. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 1: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.

...
        val webview = findViewById<View>(R.id.webview) as WebView
        webview.settings.javaScriptEnabled = true
        val url = this.intent.extras!!.getString("url")
        webview.loadUrl(url)
...

If the value of url starts with javascript:, JavaScript code that follows executes within the context of the web page inside WebView.

Example 2: The following code reads an employee ID, eid, from an HTTP servlet request, then displays the value back to the user in the servlet's response.

val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...

The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

Example 3: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name in the servlet's response.

val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...

As in Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Example 1, a source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

- As in Example 2, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- As in Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.


A number of modern web frameworks provide mechanisms to perform user input validation (including Struts and Spring MVC). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web or mobile application through an untrusted source. In the case of Inter-Component Communication XSS, the untrusted source is data received from other components that reside on the same system. In the mobile world, these are applications running on the same device. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of Persistent (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 1: The following code enables an application to load an html page within a WKWebView with data from a URL request that uses the application's custom URL scheme:

AppDelegate.m:

...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
  ...
  [self setWebContentFromURL:[url host]];
  ...
...

ViewController.m

...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...

Because the string passed to loadHTMLString: is user-controllable and JavaScript is enabled by default within a WKWebView, the user can write arbitrary content (including executable scripts) to the WKWebView via requests that use app's custom URL scheme.

Example 2: The following code reads the contents of a UITextField and displays it to the user within a WKWebView:

...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...

The code in this example operates without issues if the text within inputTextField contains only standard alphanumeric text. If the text within inputTextField includes metacharacters or source code, then the input may be executed as code by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone provide input that can cause malicious code to run on their own device? The real danger is that an attacker may use email or social engineering tricks to lure victims into performing such actions. When this is successful, the victims unwittingly reflect the malicious content through the vulnerable web application back to their own devices. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

Example 3: The following code segment queries a database for an employee with a given ID and outputs the value in the display content of a WKWebView.

...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];

NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
  NSString msg = @"Hello, " + [info valueForKey:@"name"];
  [_webView loadHTMLString:msg baseURL:nil]
  ...
}
...

As in Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Example 1, a source outside the target application makes a URL request using the target application's custom URL scheme, and unvalidated data from the URL request subsequently read back into the application as trusted data and included in dynamic content.

- As in Example 2, data is read directly from a user-controllable UI component and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- As in Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web or mobile application through an untrusted source. In the case of Inter-Component Communication XSS, the untrusted source is data received from other components that reside on the same system. In the mobile world, these are applications running on the same device. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of Persistent (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 1: The following code enables an application to load an html page within a WKWebView with data from a URL request that uses the application's custom URL scheme:

...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let name = getQueryStringParameter(url.absoluteString, "name")
    let html = "Hi \(name)"
    let webView = WKWebView()
    webView.loadHTMLString(html, baseURL:nil)
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...

Because the string passed to loadHTMLString: is user-controllable and JavaScript is enabled by default within a WKWebView, the user can write arbitrary content (including executable scripts) to the WKWebView via requests that use app's custom URL scheme.

Example 2: The following code reads the contents of a UITextField and displays it to the user within a WKWebView:

...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...

The code in this example operates without issues if the text within inputTextField contains only standard alphanumeric text. If the text within inputTextField includes metacharacters or source code, then the input may be executed as code by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone provide input that can cause malicious code to run on their own device? The real danger is that an attacker may use email or social engineering tricks to lure victims into performing such actions. When this is successful, the victims unwittingly reflect the malicious content through the vulnerable web application back to their own devices. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

Example 3: The following code segment queries a database for an employee with a given ID and outputs the value in the display content of a WKWebView.

let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    let name : String = result.valueForKey("name")
    let msg : String = "Hello, \(name)"
    let webView : UIWebView = UIWebView()
    webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
    print("Error \(error)")
}

As in Example 2, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Example 1, a source outside the target application makes a URL request using the target application's custom URL scheme, and unvalidated data from the URL request subsequently read back into the application as trusted data and included in dynamic content.

- As in Example 2, data is read directly from a user-controllable UI component and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- As in Example 3, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.