Web Development Company in Pune: Which HTTP Security Headers Your Website Needs (HSTS, CSP, nosniff and the Rest), and How to Add Them Without Breaking the Site

Web Development Company in Pune: Which HTTP Security Headers Your Website Needs (HSTS, CSP, nosniff and the Rest), and How to Add Them Without Breaking the Site

A well-built business website should send a small set of HTTP security headers: HSTS to force HTTPS, X-Content-Type-Options: nosniff to stop browsers guessing file types, a Referrer-Policy to limit what links leak, a policy to block other sites from framing your pages, and a Content-Security-Policy (CSP) to limit which scripts can run. The first four are low-risk and quick. CSP is the powerful one and the one that breaks sites, so it is introduced in report-only mode first. If a web development company in Pune tells you the site is "secure" because it has an SSL certificate, ask which of these headers it actually sends. A certificate encrypts the connection; headers tell the browser how to behave once the page arrives.

This article is for business owners and marketing managers who commission websites and want to know what to ask for, and for developers who inherit a WordPress or custom site with none of this configured. It covers what each header does, a recommended starting set, the order to roll them out, how to add them on common setups, what tends to break (chat widgets, analytics, payment pages), how to test, and a checklist for your vendor. Technical facts come from MDN Web Docs pages for each header, read in October 2026. Standards and browser behaviour evolve, so verify against the live documentation before copying values. Where I describe general practice rather than a documented rule, I say so. This is not a substitute for a security audit, and no real client is described. It does not cover payments, shipping or tax.

What a web development company in Pune should actually mean by "secure"

Security for a website has layers, and headers are one that is cheap and often forgotten.

• Hosting and updates decide whether the server and the software on it are patched. Our guide on PHP 8.1's end of life covers one common failure.
• Access control decides who can log in and with what. Our guide on keeping an NGO donation site secure covers hosting, two-factor authentication, backups and offboarding.
• Incident response decides what you do when something goes wrong. See our article on CERT-In breach reporting.
• HTTP security headers decide how the visitor's browser treats your pages: whether it insists on HTTPS, whether it lets another site frame you, whether it will run an injected script.

Headers do not fix a vulnerable plugin. What they do is shrink the damage when something else goes wrong. MDN describes CSP as defence in depth: it does not replace sanitising input, but if sanitising fails, CSP can still block an injected script from a malicious host, inline script blocks, inline event handlers and the use of eval(). That is the right mental model for the entire set: a seatbelt, not a substitute for careful driving.

One boundary to state clearly: the headers below apply to responses your server sends, so they are only as good as where they are set. A header set in a staging copy does nothing for the live site. We come back to this under testing.

The starting set, header by header

Strict-Transport-Security (HSTS)

HSTS tells the browser to use only HTTPS for your domain for a stated period. According to MDN, max-age is required and gives the number of seconds the browser should remember the rule; includeSubDomains extends it to every subdomain; and preload signals that you want the domain in browsers' built-in preload lists.

MDN gives two example values: max-age=31536000; includeSubDomains (one year) for general use, and max-age=63072000; includeSubDomains; preload (two years) when you intend to submit to the preload list, which requires at least one year, includeSubDomains and the preload token.

The risks are real and worth understanding before you switch it on:

• Subdomain lockout. With includeSubDomains, any subdomain that cannot serve HTTPS becomes unreachable in browsers that have seen the policy. Think of an old mail. or staging. host.
• Hard to undo. You cannot switch HSTS off over plain HTTP. MDN notes that max-age=0 disables it only after a browser receives the header over a secure connection, and a long max-age keeps the rule in browsers for that whole period.
• Preload is a commitment. MDN stresses that preload is not part of the HSTS specification and should not be treated as official. Do not add preload unless every subdomain supports HTTPS and you have decided to submit the domain.
• First-visit gap. HSTS applies only after a browser has made a secure connection and received the header.

A sensible rollout is to start with a short max-age such as 300 seconds, confirm that every page and subdomain works over HTTPS, then step up to a longer period. That staged approach is my recommendation from the risks above, not something MDN prescribes.

X-Content-Type-Options: nosniff

This header has one value. MDN explains that it tells the browser to trust the declared Content-Type rather than guess from the file's contents. For scripts and stylesheets, the browser blocks the file if its type does not match what is expected; for other responses, it stops the browser from treating, say, a text/plain upload as HTML. That matters where visitors can upload files, such as forms with attachments.

It is a one-line, low-risk addition. The catch is that it requires correct Content-Type headers on all your files; if a stylesheet is served as text/plain by a misconfigured server, nosniff will stop it applying, and you will see unstyled pages. That is a configuration bug worth finding anyway.

Referrer-Policy

When a visitor clicks a link or the page loads a resource, the browser may tell the destination which page they came from. MDN says strict-origin-when-cross-origin is the default when no policy is set: the full URL is sent to your own pages, only the origin (domain) goes to other sites, and nothing is sent when going from HTTPS to HTTP.

Setting it explicitly is good practice because it documents the intent and does not depend on a browser default. MDN warns about the opposite end: unsafe-url sends the full path and query string everywhere, which can leak private information held in URLs. A stricter no-referrer hides everything but may break analytics or features that rely on the referrer.

Why it matters for a Pune business: if your URLs ever carry anything sensitive, such as an order reference or a token in the query string, a lax policy can pass it to third-party scripts. The better fix is not putting such data in URLs, but the header is a safety net.

Clickjacking protection: frame-ancestors and X-Frame-Options

Clickjacking hides your page in a frame on another site so visitors click things they cannot see. MDN's X-Frame-Options page says DENY blocks all framing and SAMEORIGIN allows only your own domain; it also points to the CSP frame-ancestors directive as the more comprehensive option and notes that the old ALLOW-FROM value is obsolete. A common pairing, which MDN's page suggests for older-browser coverage, is to send both with equivalent policies, for example Content-Security-Policy: frame-ancestors 'self' and X-Frame-Options: SAMEORIGIN.

Allow framing only if you must. Some sites legitimately embed their pages elsewhere (a booking widget on partner sites, for example); in that case list the permitted origins in frame-ancestors instead.

Permissions-Policy

This header lets you switch off browser features your site does not use, such as the camera, microphone or geolocation, for your pages and for any third-party content embedded in them. MDN documents the syntax as a list of features with allowed origins, where an empty list disables a feature. For a typical brochure or ecommerce site that never asks for the camera, disabling it is a cheap guard against a compromised embed. For example, Permissions-Policy: camera=(), microphone=(), geolocation=() switches all three off, and MDN notes that an embedded frame cannot use a feature the top-level page has disabled this way. MDN also flags the header as having limited browser support at the time I read it, so treat it as a bonus layer and check the compatibility table and current feature names before you rely on it.

Content-Security-Policy (CSP)

CSP is where most of the protection, and most of the risk, lives. A policy is a series of directives, each saying where a type of resource may come from. MDN's example: default-src 'self'; img-src 'self' example.com means everything defaults to your own domain, and images may also come from example.com.

Key points from MDN's guidance:

• Inline scripts and eval() are blocked whenever default-src or script-src is present, unless you add 'unsafe-inline' or 'unsafe-eval', which MDN advises avoiding.
• Nonces and hashes are the modern way to allow specific inline scripts. A nonce is a random value generated for every response and placed on each allowed script; MDN says it must be unguessable and unique per response, so the server needs templating. A hash fits static sites, with the catch that any change to a script requires updating its hash.
• A strict CSP uses nonces or hashes rather than long allowlists of hosts, which MDN says are easy to bypass and hard to maintain. Its example is a script-src with a nonce, plus object-src 'none' and base-uri 'none'.
• Report-only mode. Content-Security-Policy-Report-Only applies a policy without enforcing it: violations are reported, but resources still load. This is how you test.

The honest warning: a strict CSP on a typical WordPress site with page builders, analytics tags, a chat widget and a payment script will block things on day one. It should be built from reports, not copied from a blog post.

A recommended starting set

A defensible baseline for a small business site (a starting point, to be adapted and tested, not a guarantee):

The order matters. Do the low-risk four first, add frame-ancestors, run the full CSP in report-only mode for a few weeks of real traffic, fix what the reports show, and only then enforce.

How to add headers on common setups

Where you set the header depends on your stack. I cannot know yours, so ask your developer where it lives and who can change it.

• Apache or LiteSpeed shared hosting (typical WordPress): headers are commonly added in the .htaccess file or the server configuration. .htaccess applies to Apache-compatible servers; it does nothing on Nginx.
• Nginx: headers go in the server configuration. Whoever manages the server needs to edit and reload it.
• A CDN or edge service such as Cloudflare: many CDNs let you add response headers centrally, which can be easier than touching the server. Check your provider's documentation for current options.
• A WordPress security plugin: some plugins add headers for you. That is convenient but adds another moving part; make sure you know what it sets and test the result.
• A framework or custom build: headers are typically set in application code or middleware, which makes them part of the repository and deployment process. Our article on staging, Git and rollback explains why that is valuable.
• A static site host: many have a configuration file for headers. Check the provider's documentation.

Whatever the method, the header must appear on the live responses. Check for it after deployment rather than assuming.

What tends to break, and how to find out

Most failures are predictable:

• Chat widgets, analytics and ad pixels. These inject inline scripts and load from third-party hosts. A CSP that does not allow them blocks them silently. Report-only mode lists each blocked item.
• Payment and booking embeds. These load scripts and frames from the provider's domain. Take the exact domains from the provider's documentation; do not guess.
• Page builders and themes that emit inline scripts and styles. These are the hardest to bring under a strict policy.
• Old subdomains that lack HTTPS, which includeSubDomains will make unreachable.
• Embedded video and maps that rely on frames; a frame-ancestors setting should not affect pages you embed, but a restrictive frame-src or default-src can.
• Mixed content, where an HTTPS page loads an HTTP image or script, which upgrade-insecure-requests (a CSP directive, per MDN) can sometimes paper over. Fix the links properly instead.

The method is the same for all: run the policy in report-only mode with a reporting endpoint, read the violation reports, decide for each one whether it is legitimate, and then either adjust the policy or remove the offending script. MDN describes the recommended approach as declaring a reporting endpoint with the Reporting-Endpoints header and referencing it with report-to, and notes report-uri is deprecated but still declared alongside for browsers that lack full support. If you do not want to run your own endpoint, ask whether your CDN or a reporting service can collect them.

A worked example (hypothetical)

Take a Pune interior design studio with a WordPress site, a contact form, Google Analytics, a chat widget and an embedded map. This is illustrative and not a real client.

Week 1: audit. The developer checks the live response headers with the browser's network panel and an online header checker. Finds: HTTPS works, no HSTS, no nosniff, no referrer policy, no framing protection.

Week 1: low-risk set. Adds X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, frame-ancestors 'self' with X-Frame-Options: SAMEORIGIN, and a restrictive Permissions-Policy. Tests the contact form, the map and the chat widget on staging, then live.

Week 1: HSTS short. Adds HSTS with max-age=300 and confirms that the main domain and the www and mail subdomains behave. Raises to a longer value later, after a month with no issues.

Weeks 2 to 5: CSP in report-only. Adds a report-only policy. Reports show the analytics tag, the chat widget, a font service and the map host. The developer lists each as an allowed source, removes one unused marketing script entirely and moves one inline snippet into a file.

Week 6: enforce. Switches the policy to enforcing for the pages that produced clean reports, keeps watching reports, and writes down the policy, the reasons for each allowed host and who must update it when a new tool is added.

The numbers of weeks are an example. What matters is that CSP was never switched on blind, and that each change had a test.

Questions to ask a web development company in Pune

1. Which security headers does the live site send today? Ask for the output of a header check, not a promise.
2. Is HSTS enabled, with what max-age, and are all subdomains on HTTPS?
3. Do you use a CSP? Was it built from report-only data?
4. Which third-party scripts does the site load, and who approved them?
5. Where are headers configured (server, CDN, plugin, code), and who can change them?
6. Are headers part of the deployment, or could a server change silently remove them?
7. How do we hear about violations? A report endpoint nobody reads is not monitoring.
8. What is the plan when we add a new tool, such as a chat widget or ad tag?
9. Will you re-test after plugin or theme updates?
10. Is this written into the maintenance scope? See our guide on website maintenance and support in Pune.

Working with Govindani Infotech

Govindani Infotech is a web design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. If you would like to know what your current site sends, we can check its response headers, list the third-party scripts it loads and tell you plainly which of the headers above are worth adding and in what order.

For new builds, our website creation work includes agreeing hosting, headers and release process at the start, and for stores, our ecommerce service page covers the extra care that checkout pages need. To talk it over, use the contact page or message us on WhatsApp.

Frequently Asked Questions

Does an SSL certificate make my website secure?

It encrypts traffic between the visitor and your server, which is essential, but it does not tell the browser how to treat your pages. Security headers such as HSTS, nosniff, a referrer policy and a Content-Security-Policy are separate and add protection on top.

What is HSTS and can it break my website?

HSTS tells browsers to use only HTTPS for your domain for a period you set. MDN warns that with includeSubDomains, any subdomain that cannot serve HTTPS becomes unreachable, and that it is hard to undo, so start with a short max-age and increase it once everything works. Add preload only if you intend to submit the domain to the preload list.

What is a Content-Security-Policy in simple terms?

It is a rule list sent with each page that tells the browser where scripts, images, frames and other resources may come from. If an attacker injects a script from an unapproved source, the browser can refuse to run it. MDN describes it as defence in depth, not a replacement for sanitising input.

Should I switch on a strict CSP straight away?

No. MDN's recommended approach is to start in report-only mode, review the violations, fix or allow what is legitimate, and enforce only once reports are clean. Sites with analytics, chat widgets and page builders almost always need this staged approach.

Can I add security headers to WordPress myself?

Often, yes, through the server configuration, a CDN or a plugin, but it depends on your hosting. Because mistakes can take pages offline or break forms, make changes on a staging copy first and test the form, the checkout and every embedded widget.

Sources:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP