Skip to content

Using Cookies in IED Application

The preferered and more secure method for setting most cookies, especially those critical for security like session IDs is by setting the Server-Side.

Key Attributes to consider for cookies

Implementing the strongest security measures for cookies often comes with a potential impact on user experience. It is a balance you need to strike based on the sensitivity of your application and its data.

SameSite=\

  • Purpose: Provides a robust defense against Cross-Site Request Forgery (CSRF) attacks by controlling when cookies are sent with cross-site requests.
  • Best Practice: Always explicitly set SameSite. Start with Strict. Only use None if absolutely necessary for legitimate cross-site functionality (e.g., third-party embeds), and always with Secure.
  • Usability Impact: If a user clicks a link from an external site (e.g., an email) that navigates to your site, and that link requires them to be logged in (i.e., needs a session cookie), the cookie will not be sent. This means the user might appear logged out or see an error, requiring them to re-authenticate.

Secure

  • Purpose: Ensures the cookie is only sent over HTTPS (encrypted connections).
  • Best Practice: ALWAYS include this attribute for all cookies if your site uses HTTPS

HttpOnly

  • Purpose: Prevents client-side JavaScript from accessing the cookie via document.cookie.
  • Best Practice: ALWAYS include this attribute for cookies that do not need to be accessed by client-side scripts, especially session IDs. This is a critical defense against Cross-Site Scripting (XSS) attacks, as it prevents an attacker from stealing session cookies even if they manage to inject malicious JavaScript.

Domain=\ and Path=\

  • Purpose: Specifies a URL path and domains that must exist in the requested URL for the browser to send the cookie.
  • Best Practice: Use more specific paths if a cookie is only relevant to a particular section. For domain its usually omitted, letting the browser default to the exact host that set it.

Security Header

Beyond securely setting cookies, HTTP security headers provide another critical layer of protection for your web application. These headers instruct the browser on how to behave when interacting with your site, mitigating common web vulnerabilities like Cross-Site Scripting (XSS), Clickjacking, and MIME-sniffing attacks.

Key Attributes to Consider for Security Headers

Applying strict security headers strengthens your application’s defense against common web vulnerabilities, but they can also influence how browsers handle content and functionality. Choosing the right configuration requires balancing security with usability to ensure that protection does not unintentionally break core features of your application.

Content-Security-Policy (CSP)

  • Purpose: Helps prevent XSS and data injection attacks by specifying which sources the browser can load resources from.
  • Best Practice: Define a strict CSP that only allows trusted sources for scripts, styles, images, etc. Avoid using 'unsafe-inline' and 'unsafe-eval' unless absolutely necessary.

  • Example:

    Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

X-Frame-Options

  • Purpose: Protects against clickjacking by controlling whether your site can be embedded in frames.
  • Best Practice: Use DENY to prevent all framing, or SAMEORIGIN to allow only your own domain.

  • Example:

    X-Frame-Options: DENY

X-Content-Type-Options

  • Purpose: Prevents browsers from MIME-sniffing a response away from the declared content-type.
  • Best Practice: Always set to nosniff.

  • Example:

    X-Content-Type-Options: nosniff

Referrer-Policy

  • Purpose: Controls how much referrer information is sent with requests.
  • Best Practice: Use no-referrer or strict-origin-when-cross-origin for privacy.

  • Example:

    Referrer-Policy: strict-origin-when-cross-origin

Strict-Transport-Security (HSTS)

  • Purpose: Enforces HTTPS by telling browsers to only connect securely.
  • Best Practice: Set a long max-age and include subdomains.

  • Example:

    Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Regularly review and update your security headers to address new threats and best practices.