The website security basics worth fixing.

A public view, with clear limits.

On 2026-10-30, we ran a local Python port of our passive website checker against 207 India-connected fintech, B2B SaaS and AI product websites. It reads public pages, a bounded set of known file paths and DNS records, and performs TLS handshakes. Requests identify our checker and link to the free check. We do not log in, submit forms or try exploits. We respect our exclusion list and stop at a home-page firewall challenge. Owners can opt out under our scanning policy.

The final eligible sample is 93 below the planned 300 websites. We removed out-of-scope candidates during source review. This is a public-directory convenience sample, not a market estimate. India connections come from directory locations and India-focused investor portfolios, including cross-border businesses. We did not independently verify legal domicile. Source headcounts were in the preferred range of 20 to 500 for 45 selected websites; headcount was unverified for 162. These are counts as at 2026-10-30. Fintech takes priority when sectors overlap, followed by explicit AI products, then B2B software.

We obtained readable sites for 193 of 207 selected websites on 2026-10-30. The results below use measured observations only. Blocked, timed-out and inapplicable checks appear separately. A missing header does not establish an exploitable vulnerability, and a passing check does not establish that an application is secure.

Inspect the anonymous aggregate data and calculation notes. Per-domain results stay private. Rates are rounded to whole percentages after pooling counts.

Start with the defences a browser can use.

Each label shows the affected count and measured sample size for 2026-10-30. The bars compare observed rates, not the severity of a vulnerability.

Read the sample before comparing grades.

The checker has no E band. Research grades normalise measured weights before blending the basic and deeper checks. They are not directly comparable with grades from the live checker, which handles skipped checks differently. Segment differences may reflect size, hosting or sample selection; they do not establish that a sector is safer.

What passed, what needs review.

Unknown / n/a includes blocked probes, timeouts and checks that do not apply. A software-identifying header is reported separately from an exact version. Cookie checks describe the public home page. A subdomain name that suggests testing or administration is a reason to review ownership, not proof of a security flaw.

The headline rates and their denominators.

SPF missing or soft includes invalid, neutral and permissive records. DMARC absent is distinct from monitoring mode. The combined file-exposure measure is known positive when any signature is confirmed; a negative requires completed probes for all components. Lower coverage can bias that rate. security.txt presence means a Contact line was found; it does not validate the contact or expiry. TLS support needs a successful handshake. An ambiguous failure is unknown. No rate describes actual email delivery, authenticated cookies or an exhaustive inventory.

What we could not grade.

Firewall challenges are not a fault on the site. We did not retry them or include their block pages in the grade. These exclusions can change the mix of sites that remain, so the results should not be generalised to all Indian businesses.

Make the next change small and verifiable.

1. Keep source history private

   Block access to /.git on the web server (or deploy without it) today, then change any secrets that were in the code.

2. Remove confirmed public sensitive files

   Remove these files from the web folder or block them on the server. Backups and logs belong outside the site entirely.

3. Retire legacy TLS protocols

   Disable TLS 1.0 and 1.1 on the web server or load balancer, keeping TLS 1.2 and 1.3.

4. Move mail authentication towards enforcement

   After checking the reports, move to p=quarantine and then p=reject.

5. Introduce an enforced script policy

   Start with Content-Security-Policy: default-src 'self' and add the sources your site really uses.

6. Choose who may frame your pages

   Add X-Frame-Options: DENY (or frame-ancestors 'none' in your CSP).

7. Keep browsers on HTTPS

   Add the header Strict-Transport-Security: max-age=31536000; includeSubDomains

8. Review the cookies that need protection

   Set Secure on every cookie (and HttpOnly and SameSite where scripts don’t need them).

These fixes come from the checker. Test policies against the sources, embeds, subdomains and email senders your service needs before enabling them widely. Verify the change at the response or DNS record after release.

Check your own starting point.

Use the free website check to see the public configuration of a site you own or have permission to test. When you need to test roles, APIs and transaction flows, our fintech VAPT service covers the application behind the front page.