Same-Site cookies

Same-Site cookies is the setup of the SameSite attribute for cookies with value selection for your scenarios: Lax (a reasonable balance, the cookie is not sent on most cross-site requests), Strict (the strictest, but breaks following external links with authorization), None (needed for legitimate cross-site scenarios — but requires Secure). Honestly about the scope, this matters: SameSite reduces the risk of CSRF (cross-site request forgery), a substantial modern mechanism, but NOT full protection against CSRF by itself: sensitive actions still need anti-CSRF tokens (751) — this is layered protection, not 'set SameSite and forget'. Honestly about compatibility, this is key: a wrong value breaks legitimate cross-site scenarios — embedded payment forms, widgets, login via a third-party domain (OAuth), iframe integrations. So we select a value for EACH cookie and scenario, rather than setting Strict 'on everything'. Honestly about the prerequisite: SameSite=None requires Secure (and therefore HTTPS — 736). Honestly about access: access to the code/config where cookies are set is needed. Honestly about the platform: on some site builders/SaaS (Tilda, Wix, Shopify, etc.) there may be no direct access to cookie attributes — we check in advance whether implementation is possible specifically for you, and if not, we will say so honestly. Honestly about scope over time: the setup applies to EXISTING cookies and scenarios; when new functions/cookies are added, a repeat adjustment will be required. Honestly about verification: some edge scenarios surface only on real users after rollout — we test and review with you, but final verification across all business scenarios requires your participation. An important boundary: this is the SameSite attribute (an anti-CSRF layer); full tokens are 751, the HTTPOnly/Secure flags are 758. Picture this: instead of 'another site sends a request with your cookie on behalf of a user' — the browser itself does not give the cookie on cross-site requests. The base price starts from 9,000 ₽ per project.

• The cookie is sent on cross-site requests — CSRF risk.
• The SameSite attribute is not set or set at random.
• Strict 'on everything' breaks external-link logins and integrations.
• Payment forms/widgets break due to a wrong SameSite.

• An audit of cookies and cross-site scenarios (payments, OAuth, widgets)
• Selecting the SameSite value for each cookie (Lax/Strict/None)
• Setting Secure for cookies with SameSite=None
• Checking legitimate cross-site scenarios did not break
• Indicating boundaries (does not replace anti-CSRF tokens)
• Pairing with tokens (751) if needed
• Checking application
• Handover and review with you

• Cookies are not sent on excess cross-site requests
• CSRF risk reduced at the browser level
• Legitimate integrations (payments/OAuth) preserved
• A substantial anti-CSRF layer (full protection — with tokens)

• We capture cookies and all cross-site scenarios; collect access
• We select SameSite for each cookie, set it, check integrations
• We verify nothing broke, review boundaries with you

• Will SameSite fully protect against CSRF?

  No, by itself — no. SameSite is a substantial modern layer (the browser does not give the cookie on cross-site requests), but sensitive actions still need anti-CSRF tokens (751). The right way is several layers together, not 'set SameSite and forget'.

• Set Strict on everything — will it be safer?

  Safer, but Strict 'on everything' breaks legitimate scenarios: following an external link with authorization, login via a third-party domain (OAuth), embedded payments. So we select a value for each cookie and scenario: Lax somewhere, Strict somewhere, None+Secure somewhere.

• How is this different from CSRF protection (751)?

  751 is anti-CSRF tokens in the application itself (full action protection). This service is the SameSite attribute at the browser level (an additional layer). It is logical to do them together; we will honestly say whether you need only SameSite or the combination with tokens.