CDS Security Intelligence · Practical checklist
Website security checks help a small or medium-sized business identify configuration issues that may deserve attention before they become operational problems. You do not need to be a security engineer to start asking the right questions—but you do need to interpret the evidence carefully.
A quick external check can reveal useful signals about HTTPS, browser security headers, exposed technology indicators, cookies, DNS and email configuration. It cannot prove that a website is completely secure, and an individual missing control does not automatically prove that a site is vulnerable or compromised.
Why website security checks matter
A business website is more than a brochure. It depends on hosting, DNS, certificates, browser behaviour, forms, cookies, a content-management system and sometimes customer or employee workflows. Those components can affect availability, trust and the handling of information.
A first-pass review helps an owner record what is observable, identify questions that need validation and decide whether a deeper assessment is appropriate. Treat it as a starting point—not a security certificate.
1. Confirm that HTTPS is actually enforced
Check the secure connection and redirect behaviour
Open both the HTTPS and HTTP versions of your public website. Observe whether the secure version loads correctly and whether an HTTP request redirects to HTTPS where appropriate. Also check that the certificate is valid and that the page does not report mixed-content problems.
What to look for
- Certificate validity and a successful HTTPS response.
- HTTP-to-HTTPS redirect behaviour.
- Browser warnings or mixed-content indicators.
- Consistent canonical URLs for the preferred page version.
Why it matters
Correctly configured HTTPS protects data in transit between a visitor’s browser and the website. A certificate alone does not establish complete website security.
2. Review security response headers
Inspect the headers sent by the server
HTTP response headers can help browsers apply security-related behaviour. Depending on the site and its architecture, useful controls may include HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Content-Type-Options and appropriate framing and referrer controls.
What to look for
- Which relevant headers are present in the captured response.
- The actual values and whether they are intentionally configured.
- Whether the policy is applied consistently to the relevant pages and responses.
- Whether a policy could interfere with legitimate scripts, embeds or site functionality.
Why it matters
Missing or limited headers can point to hardening opportunities. Header presence is a positive control signal, not proof of complete protection. The right policy depends on the application and how it is used.
3. Check the technology footprint
Understand the major components that are observable
Identify platform indicators exposed by the public site. These may include its content-management system (CMS), framework, server, language/runtime, version information and major third-party components.
What to look for
- Whether the site appears to use WordPress or another CMS.
- Observable framework, runtime or server indicators.
- Version information and third-party components, where exposed.
- Technology that may need lifecycle, patching or configuration review.
Why it matters
An accurate technology inventory helps a business plan updates, lifecycle reviews and configuration management. An older-looking indicator should be validated against reliable version and support information before drawing conclusions.
4. Review cookies and browser-facing controls
Check security-relevant cookie attributes where applicable
Where a website uses logins, forms, sessions or other stateful functions, review whether relevant cookies use appropriate security attributes. The correct configuration depends on the application’s purpose and how its sessions work.
What to look for
- Secure: whether a cookie is restricted to secure transport where required.
- HttpOnly: whether browser scripts are prevented from reading a cookie when that restriction is appropriate.
- SameSite: whether cross-site cookie behaviour is configured appropriately for the application’s needs.
- Consistency across relevant cookies, paths and application functions.
Why it matters
Appropriate cookie settings can reduce certain types of browser and session exposure. They should be assessed alongside the application’s behaviour, authentication design and threat model.
5. Check DNS and email security basics
Review the domain’s public records and email controls
DNS is part of a business’s digital infrastructure. Review the public records and, where business email is in scope, examine the domain’s sender-authentication controls.
What to look for
- A/AAAA: address records for the domain or relevant hostnames.
- MX: mail-routing records.
- NS: nameserver records.
- TXT: text records, which may include email-authentication policies.
- SPF, DKIM and DMARC: email-authentication controls, where applicable.
- Unexpected or inconsistent records compared with the business’s intended setup.
Why it matters
DNS and email controls can affect reliability, domain governance and resistance to email spoofing. The meaning of a record depends on the domain’s actual infrastructure and email-provider configuration.
A 15-minute website security review checklist
Use this table to record the first-pass review. Write down the date, the page or hostname checked, the evidence observed and the next action. Mark an item “needs review” when you cannot confidently interpret it.
| Check | Observed? | Needs review? | Owner / next action |
|---|---|---|---|
| HTTPS and redirect behaviour | ☐ Yes / ☐ No / ☐ Unknown | ☐ Yes / ☐ No | Record evidence and validate |
| Security response headers | ☐ Yes / ☐ No / ☐ Unknown | ☐ Yes / ☐ No | Review policy and applicability |
| Technology inventory | ☐ Yes / ☐ No / ☐ Unknown | ☐ Yes / ☐ No | Confirm versions and support status |
| Cookie controls | ☐ Yes / ☐ No / ☐ Unknown | ☐ Yes / ☐ No | Validate against application behaviour |
| DNS and email controls | ☐ Yes / ☐ No / ☐ Unknown | ☐ Yes / ☐ No | Compare with intended domain setup |
This checklist is an initial review aid, not a pass/fail certification or a substitute for a risk-based security assessment.
How to interpret a professional website security finding
A useful audit should separate the evidence from the interpretation and recommended action. A practical reporting sequence is:
The strength of a business-impact statement should never exceed the strength of the evidence.
“CSP was not observed in the captured response” is a specific observation. “Review and strengthen browser-side policy controls” is a reasonable next step. “Your website is hacked” is a different claim and requires different evidence.
What our September 2026 review illustrates
In a September 2026 authorized passive review of 92 public-facing targets, the CDS/AuthSetu review recorded 9,977 normalized observations. In the V5 normalized dataset, HSTS was observed on 50 of 92 targets (54.3%), while CSP was observed on 45 of 92 targets (48.9%).
The review also illustrated why evidence quality matters: earlier parser output and later normalized output did not agree on every technology or header field. A responsible benchmark distinguishes stable observations from parser-dependent indicators instead of turning every automated signal into a vulnerability claim.
When a checklist is not enough
A passive external checklist does not replace every type of security assessment. Depending on the business’s exposure and authorization, a deeper review may require:
- A penetration test conducted under a defined scope and authorization.
- An authenticated assessment of relevant application functions.
- A secure-code review.
- An incident-response investigation when there is evidence of a possible incident.
- A separate legal or compliance assessment where required.
If the business handles sensitive customer data, payments, employee systems or privileged workflows, the assessment depth should match the actual risk and the authorization granted.
Recommended next steps for a business owner
- Run the five checks against the intended public website and domain.
- Record the date, hostname, observable evidence and any uncertainty.
- Validate findings that could affect business operations before assigning severity.
- Prioritize remediation based on verified exposure, business context and practical risk.
- Arrange a deeper, explicitly scoped assessment if the initial review raises material questions.
Need a clearer picture?
Turn website security signals into actionable findings
Chaitanya Digital Solutions helps businesses review their digital infrastructure and understand which technical observations need validation, remediation or a deeper assessment. The scope should be agreed in advance; a first-pass review is not represented as a penetration test.
Discuss your website requirementsFurther reading
- MDN: HTTP response headers — background on browser-facing response headers.
- OWASP Secure Headers Project — security-header guidance and context.
- NIST Cybersecurity Framework — a broader framework for managing cybersecurity risk.
About this article: Educational guidance prepared by Chaitanya Digital Solutions. Publicly observable indicators can be incomplete or misclassified. Revalidate findings against the live environment and intended architecture. This article does not imply exploitation, unauthorized access or a guarantee of security.