Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies por um canal não criptografado pode expô-los a ataques de detecção de rede. O sinalizador seguro ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.

Exemplo 1: No exemplo abaixo, um cookie é criado sem definir o parâmetro isSecure como true.

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o parâmetro isSecure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego da rede por conexões sem fio não criptografadas é uma tarefa simples para os invasores. O envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.

Exemplo: No exemplo a seguir, um cookie é adicionado à resposta sem definir a propriedade Secure.

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados ou identificadores de sessão privados, ou carrega um token CSRF.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo abaixo, o cookie é adicionado à resposta sem definir a propriedade Secure como true.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo a seguir, o cookie é adicionado à resposta sem definir o sinalizador Secure.

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

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

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados ou identificadores de sessão privados, ou carrega um token CSRF.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo a seguir, o cookie é adicionado à resposta sem definir o sinalizador Secure.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo a seguir, o cookie é adicionado à resposta sem definir o sinalizador Secure.

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

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

Os navegadores dão suporte à propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de criação de script entre sites muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Com HttpOnly desativado, os invasores têm acesso mais fácil aos cookies do usuário.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade httpOnly.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

Os navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, httpOnly = false))

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O seguinte código cria um cookie de sessão sem configurar o parâmetro HttpOnly como true.

session_set_cookie_params(0, "/", "www.example.com", true, false);

Os navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.

Exemplo 1: As configurações abaixo definem explicitamente os cookies de sessão sem definir a propriedade HttpOnly.

...
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',
    ...
)
...
SESSION_COOKIE_HTTPONLY = False
...

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.None;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

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

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

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

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

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

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O parâmetro samesite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro samesite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

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

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de ler um cookie, os invasores podem executar um "ataque de envenenamento de cookie" usando insecure.example.com para criar seu próprio cookie excessivamente amplo que substitui o cookie em Secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina um cookie de ID de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de ler um cookie, pode ser possível aos invasores realizar um "ataque de envenenamento de cookie" usando insecure.example.com para criar o cookie próprio e excessivamente amplo que substitui o cookie secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

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

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem acessíveis no caminho do contexto raiz ("/"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum. Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem cookies para serem o caminho do contexto raiz "/". No entanto, fazer isso expõe o cookie a todos os aplicativos Web no mesmo nome de domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem cookies para serem acessíveis no caminho do contexto raiz ("/"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1:
Suponha que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clica nesse link, o navegador envia o cookie definido por /MyForum para o aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.

Além de ler um cookie, os invasores podem executar um "ataque de envenenamento de cookie" usando /EvilSite para criar seu próprio cookie excessivamente amplo que substitui o cookie em /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de ler um cookie, pode ser possível aos invasores realizar um "ataque de envenenamento de cookie" usando /EvilSite para criar o cookie próprio e excessivamente amplo que substitui o cookie /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1: Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

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

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem cookies de sessão como sendo um domínio base, como ".example.com". Isso expõe o cookie de sessão a todos os aplicativos Web sob o domínio base e todos os subdomínios. O compartilhamento de cookies de sessão entre aplicativos pode causar uma vulnerabilidade em um aplicativo para causar um comprometimento em outro.

Exemplo 1:
Imagine que você tem um aplicativo seguro implantado em http://secure.example.com/ e o aplicativo define um cookie de sessão com um domínio ".example.com" quando os usuários fazem login.

Por exemplo:

session_set_cookie_params(0, "/", ".example.com", true, true);

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Os desenvolvedores muitas vezes definem cookies de sessão para serem o caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no mesmo nome de domínio. O vazamento de cookies de sessão pode comprometer contas porque um invasor pode roubar o cookie de sessão usando uma vulnerabilidade em qualquer um dos aplicativos no domínio.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

session_set_cookie_params(0, "/", "communitypages.example.com", true, true);

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, seu navegador enviará o cookie de sessão definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o cookie de sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.Lax;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina cookies de sessão com o atributo SameSiteStrictMode para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita SameSiteLaxMode no atributo SameSite para cookies de sessão.

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

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

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

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina cookies de sessão com o atributo Strict para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita o modo Lax no atributo SameSite para cookies de sessão.

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

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor atrair um usuário desavisado para o site de terceiros que ele controla, o invasor poderá fazer solicitações que incluam automaticamente o cookie de sessão com autorização do usuário. Isso efetivamente dá ao invasor acesso com a autorização do usuário.
Defina cookies de sessão como Strict para o parâmetro SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita Lax no atributo samesite para cookies de sessão.

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

A maioria dos ambientes de programação da Web adota como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados no disco) e são perdidos quando o navegador é fechado. Os programadores podem especificar que os cookies persistam nas sessões do navegador até uma data futura. Esses cookies são gravados no disco e sobrevivem às sessões do navegador e reinicializações do computador.

Se as informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque os cookies persistentes costumam expirar em um futuro distante. Os cookies persistentes costumam ser usados para traçar o perfil dos usuários conforme eles interagem com um site. Dependendo do que for feito com esses dados de rastreamento, será possível usar cookies persistentes para violar a privacidade dos usuários.

Exemplo 1: O código a seguir define um cookie para expirar em 10 anos.

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

A maioria dos ambientes de programação da Web assumem como padrão a criação de cookies não persistentes. Esses cookies residem apenas na memória do navegador (não são gravados em disco) e se perdem quando o navegador é fechado. Os programadores podem especificar que os cookies se mantenham persistentes entre sessões do navegador até uma determinada data no futuro. Esses cookies são gravados no disco e sobrevivem entre sessões de navegador e reinicializações do computador.

Se informações privadas forem armazenadas em cookies persistentes, os invasores terão uma janela de tempo maior para roubar esses dados, especialmente porque cookies persistentes são muitas vezes definidos para expirarem em um futuro distante. Cookies persistentes costumam ser usados para definir perfis de usuários à medida que estes interagem com um site. Dependendo do que é feito com esses dados de rastreamento, é possível utilizar cookies persistentes para violar a privacidade dos usuários.
Exemplo: O código a seguir define um cookie para expirar em 10 anos.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    cookie.Expires = DateTime.Now.AddYears(10);;