Security headers

Security headers is the setup of a set of protective HTTP headers and verification of their application across the whole site: X-Frame-Options / frame-ancestors (protection against clickjacking — embedding your site in someone else's iframe), X-Content-Type-Options (against MIME-sniffing), Referrer-Policy (control of address leakage), Permissions-Policy (disabling excess browser APIs: camera, geolocation, etc.), and related ones. Honestly about the scope, this matters: these headers close SPECIFIC classes of attacks at the browser level (clickjacking, MIME-sniffing, referrer leakage) — a substantial layer, but NOT full protection: they do not close XSS in the code (content needs CSP — 754), injections (753) and logic vulnerabilities. Honestly about the effect: reduction of certain risks, not 'the site is invulnerable'. Honestly about compatibility: overly strict settings can break something (for example, if your widget must be embedded in a partner's iframe) — we tune for your real scenario and verify. Honestly about maintenance: when adding new third-party services the headers may need updating. Honestly about access: access to the server/config is needed. An important boundary: this is the set of security headers in general, while CSP (754) and HSTS (756) are separate specialized headers (can be done together but are different services). Picture this: instead of 'the site can be embedded in someone else's iframe and shown to a user' — a whole class of simple attacks is closed at the browser level. The base price starts from 12,000 ₽ per project; it depends on the number of subdomains and third-party services.

• The site can be embedded in someone else's iframe (clickjacking) and trick a user.
• The browser guesses the file type (MIME-sniffing) — risk of executing malicious content.
• Page addresses leak to third-party sites via referrer.
• The browser has access to excess APIs (camera, geo) without need.

• Setting up X-Frame-Options / frame-ancestors (anti-clickjacking)
• Setting up X-Content-Type-Options (anti-MIME-sniffing)
• Setting up Referrer-Policy and Permissions-Policy
• Choosing values for your real scenario (without breakage)
• Checking application across the whole site
• Indicating boundaries (does not close XSS/injections)
• Checking compatibility
• Handover and review with you

• Clickjacking and MIME-sniffing are closed
• Control of referrer leakage and excess permissions
• A substantial protection layer at the browser level
• Reduction of a class of simple attacks (full security — separate)

• We capture current headers, discuss embedding scenarios; collect access
• We set up the header set for your case, check compatibility
• We verify application across the site, review boundaries with you

• After the headers, will the site definitely not be hacked?

  No, that cannot be promised. Security headers close specific classes of attacks at the browser level (clickjacking, MIME-sniffing, referrer leakage) — an important layer, but not the whole protection: XSS in the code, injections and logic vulnerabilities are closed by separate measures (CSP, code audit). It is part of the defense, not a guarantee of invulnerability.

• Will the headers break anything?

  They can, if set too strictly: for example, X-Frame-Options will block embedding your widget in a partner's iframe. That is why we choose values for your real scenario and check compatibility, rather than setting the strictest 'blindly'.

• How is this different from CSP and HSTS?

  CSP (754) and HSTS (756) are separate specialized headers (content and transport protection). This service is about the set of other protective headers (clickjacking, MIME, referrer, permissions). It is logical to do them together, but they are different works; we will honestly say what exactly you need.