Website Security Best Practices: 2026 Checklist

Website security is a continuing risk-management process. It covers the public website, administrator accounts, forms, dependencies, hosting, backups, APIs, third-party services and the people who control them.

HTTPS is necessary, but it does not protect a weak password, exposed API key, vulnerable plugin, broken authorisation rule or untested backup.

This guide gives Indian small and medium businesses a practical baseline for business websites, WordPress sites and custom web applications. It is educational guidance, not a guarantee that a system is secure or a substitute for a qualified security assessment.

Quick Answer

Prioritise these controls:

1. maintain an inventory of domains, hosting, applications and owners;
2. enforce HTTPS and secure browser headers;
3. use strong authentication and least-privilege authorisation;
4. validate all untrusted input on the server;
5. update software and remove unused components;
6. protect secrets and production access;
7. create tested backups;
8. log important events and monitor failures;
9. prepare an incident response plan;
10. review controls after every material change.

Security work should be based on risk and evidence, not a badge or plugin count.

Identify What You Are Protecting

Start with an asset inventory.

Record account recovery methods and remove former staff or vendor access promptly. A business should not discover during an incident that its domain or hosting belongs only to an unavailable contractor.

Match Controls to the Website Type

Static business website

The main risks are domain takeover, unsafe deployment access, vulnerable forms, third-party scripts and stale dependencies.

WordPress website

The attack surface includes WordPress core, themes, plugins, administrator accounts, file permissions, hosting and database access.

Ecommerce website

Add payment configuration, customer data, order workflows, plugins, webhooks and fraud-related risk.

Custom web application

Add authentication, authorisation, data isolation, APIs, file uploads, business logic, secrets, audit records and deployment pipelines.

Do not copy a checklist from one type and assume it covers another.

1. Protect Domain, DNS and Hosting Accounts

The domain is a critical business asset.

• Keep registration in a business-controlled account.
• Enable multi-factor authentication.
• Use a strong, unique password stored in a password manager.
• Maintain current recovery email and phone details.
• Restrict who can change DNS records.
• Enable registrar lock where appropriate.
• Document renewal and billing ownership.
• Review nameservers and DNS records after vendor changes.

Apply the same controls to hosting, cloud, CDN and deployment accounts. Shared passwords sent through chat are difficult to revoke and audit.

2. Enforce HTTPS Correctly

HTTPS protects data in transit between the browser and server.

Verify:

• HTTP redirects directly to the preferred HTTPS host;
• the certificate is valid and renews automatically;
• mixed HTTP resources are removed;
• secure cookies use the Secure attribute;
• sensitive pages do not load insecure third-party content;
• the canonical domain is consistent.

Consider HTTP Strict Transport Security after confirming every required subdomain supports HTTPS. A mistaken HSTS configuration can make a subdomain inaccessible, so deploy it deliberately.

3. Use Strong Authentication

Authentication proves who the user is.

Baseline controls:

• individual accounts;
• strong password policy;
• MFA for hosting, domain, email and privileged admin access;
• rate limiting or equivalent protection;
• secure password reset;
• generic login errors that do not reveal whether an account exists;
• session expiry and revocation;
• re-authentication for sensitive changes;
• monitoring for repeated failures.

Never store plaintext passwords. Custom systems should use established framework authentication and secure password hashing rather than a home-grown implementation.

The OWASP Authentication Cheat Sheet provides implementation guidance.

4. Enforce Authorisation on the Server

Authorisation decides what an authenticated user can do. It must be checked for every protected action and resource.

A hidden button is not access control. A user may call an API directly.

For each role:

• list permitted actions;
• deny access by default;
• verify company or tenant ownership;
• check object-level access;
• protect exports and downloads;
• restrict admin actions;
• log sensitive permission changes;
• test horizontal and vertical access.

In a multi-company application, changing an invoice ID must never reveal another company’s record. Company scope must be enforced in the backend query and business logic.

Use the OWASP Authorization Cheat Sheet as a technical reference.

5. Validate Untrusted Input

Every form, URL parameter, uploaded file, API request and webhook payload is untrusted.

Server-side validation should check:

• required fields;
• type;
• length;
• format;
• allowed values;
• numeric range;
• relationships;
• business rules;
• file type and size;
• ownership and permission.

Browser validation improves usability but can be bypassed.

Prefer allowlists when the valid format is known. Encode output for its context and use parameterised database queries or framework ORM features. The OWASP Input Validation Cheat Sheet covers common patterns.

6. Secure Contact and Lead Forms

Forms can attract spam, automated abuse and data leakage.

Use:

• server-side validation;
• rate limits;
• honeypot or challenge controls where needed;
• request size limits;
• safe error messages;
• email header protection;
• input sanitisation and output encoding;
• privacy notice;
• minimal data collection;
• spam monitoring.

Do not send sensitive form content to multiple unmanaged inboxes. Define retention and access. Never place secret keys in browser code to protect a form.

7. Protect Secrets and Configuration

Secrets include database passwords, API keys, signing keys, payment credentials and service tokens.

• Store secrets in environment or secret-management systems.
• Keep production secrets out of source control.
• Restrict access by environment and role.
• Rotate exposed or former-vendor credentials.
• Use separate test and production values.
• Avoid logging tokens or passwords.
• Review public JavaScript bundles for accidental exposure.
• Document the owner and renewal or rotation process.

A public key intentionally used in browser code is different from a private secret. Follow the provider’s security model and apply domain or API restrictions where supported.

8. Update Dependencies and Remove Unused Components

Maintain an inventory of:

• framework;
• runtime;
• packages;
• plugins;
• themes;
• server software;
• build tools;
• third-party scripts.

Review security updates and compatibility before release. Remove unused plugins, themes and packages because disabled or forgotten components may still increase risk.

For WordPress, follow the official WordPress hardening guidance and WordPress update documentation.

Updates should follow a controlled process:

1. backup;
2. stage or test;
3. review compatibility;
4. deploy;
5. verify critical flows;
6. monitor;
7. document.

9. Use Secure Browser Headers

Headers can reduce common browser-side risks.

Depending on the site, review:

• Content-Security-Policy;
• Strict-Transport-Security;
• X-Content-Type-Options;
• Referrer-Policy;
• Permissions-Policy;
• frame restrictions through CSP frame-ancestors;
• secure cookie attributes.

Content Security Policy should match the resources the site actually uses. Begin with observation or report-only mode when appropriate, then tighten it. Copying a policy without testing can break analytics, payments, forms or embedded tools.

10. Protect APIs and Webhooks

APIs require more than a hidden endpoint.

• authenticate callers;
• authorise every action;
• validate payloads;
• rate-limit abuse-prone routes;
• use idempotency for payment or order events;
• verify webhook signatures;
• prevent replay where supported;
• store secrets safely;
• return minimal data;
• log failures without sensitive payloads;
• define timeout and retry behaviour;
• test cross-company access.

Do not trust a request simply because it came from the frontend.

For payment webhooks, verify the provider signature before changing payment or order state. Record event identifiers so a repeated delivery does not create duplicate actions.

11. Secure File Uploads and Downloads

File features require careful control.

Uploads:

• allow only required types;
• validate content, not only file extension;
• limit size;
• generate safe storage names;
• prevent executable files from running;
• scan files where risk requires;
• store outside direct public execution paths;
• control who can access the result.

Downloads:

• authorise access on every request;
• avoid predictable public URLs for private files;
• set safe response headers;
• prevent path traversal;
• log sensitive exports.

A link that is difficult to guess is not a replacement for authorisation.

12. Back Up and Test Restore

A backup is useful only if it can be restored.

Define:

• what is backed up;
• frequency;
• retention;
• encryption;
• storage location;
• access;
• recovery time objective;
• recovery point objective;
• restore owner;
• test schedule.

Keep at least one backup isolated from the primary system where practical. Test restoration with a documented result. A daily “backup successful” email does not prove recovery.

For a business website, back up content, database, media, configuration and deployment information as applicable.

13. Log, Monitor and Alert

Collect actionable events:

• login failures;
• password and MFA changes;
• permission changes;
• admin actions;
• application errors;
• webhook failures;
• unusual request volume;
• backup failures;
• deployment events;
• security-control failures.

Protect logs from unauthorised access and avoid recording passwords, tokens or unnecessary personal data. Set alerts only for events someone can investigate.

Uptime monitoring alone cannot detect a compromised but still-visible website. Add integrity, application and search monitoring according to risk.

14. Reduce Third-Party Risk

Every chat widget, analytics tag, form provider, font, plugin and embedded tool adds dependency.

Review:

• purpose;
• data collected;
• permissions;
• script source;
• owner;
• renewal;
• privacy impact;
• failure behaviour;
• removal plan.

Remove tools that are not used. Limit privileged integrations and use separate accounts where possible.

15. WordPress Security Checklist

• Keep core, plugins and themes updated.
• Remove unused themes and plugins.
• Use trusted sources.
• Restrict administrator accounts.
• Enable MFA for privileged users.
• protect backups and database credentials;
• use secure file permissions;
• disable unnecessary editing or features according to hosting setup;
• test updates in staging when risk is material;
• monitor file and admin changes;
• use a maintained PHP version;
• keep the hosting account secure.

A security plugin may support monitoring or hardening, but it cannot compensate for abandoned plugins, shared admin passwords or uncontrolled hosting access.

16. Custom Web App Security Checklist

• Use maintained frameworks and libraries.
• Define role and object permissions.
• Enforce tenant or company scope in backend code.
• Validate every API input.
• Protect secrets.
• use CSRF protection where the authentication model requires it;
• configure CORS narrowly;
• use secure session or token handling;
• prevent injection and unsafe output;
• restrict file operations;
• log sensitive changes;
• scan dependencies;
• separate environments;
• test backup and restore;
• review high-risk flows before release.

The OWASP Top 10:2025 is a useful awareness baseline, but it is not a complete test plan.

17. Prepare an Incident Response Plan

Define before an incident:

1. who receives the alert;
2. who can isolate the system;
3. how access is preserved or revoked;
4. how evidence is retained;
5. how affected parties are assessed;
6. who manages legal or contractual communication;
7. how recovery is approved;
8. how credentials are rotated;
9. how monitoring is increased;
10. how lessons become controls.

Do not immediately delete all logs or rebuild the server without preserving evidence. Escalate to qualified legal, privacy and security professionals when personal data or regulated obligations may be involved.

Security Acceptance Checklist

Before launch, verify:

• [ ] Domain and hosting are business-controlled.
• [ ] MFA is enabled for critical accounts.
• [ ] HTTPS and preferred-domain redirects work.
• [ ] Admin and API authorisation are tested.
• [ ] Company or tenant isolation is tested.
• [ ] Forms and APIs use server-side validation.
• [ ] Secrets are outside source control.
• [ ] Dependencies are reviewed and current.
• [ ] Security headers are tested.
• [ ] File upload and download rules are enforced.
• [ ] Backups exist and restoration has been tested.
• [ ] Logs exclude secrets and sensitive data.
• [ ] Alerts have an owner.
• [ ] Third-party scripts are inventoried.
• [ ] Privacy and retention rules match actual collection.
• [ ] Incident contacts and recovery steps are documented.

Practical Security Test Scenarios

Ask the delivery team to test:

1. Can a normal user call an admin API?
2. Can one company user access another company’s record by changing an ID?
3. Does a repeated payment webhook create a duplicate update?
4. Can an oversized or disguised file be uploaded?
5. Does password reset expose account existence?
6. Can a removed team member still sign in?
7. What happens when the database or email service is unavailable?
8. Can a backup be restored into a clean environment?
9. Are secrets visible in logs or browser bundles?
10. Can an invalid form payload bypass browser validation?

These are starting scenarios, not a complete penetration test.

Current VASUYASHII Boundary

VASUYASHII can include security-oriented requirements such as role-based access, server-side validation, company-scoped APIs, secure deployment configuration and backup planning within an agreed web or software scope.

The exact controls, testing depth, compliance requirements, monitoring and incident support depend on the system and contract. A standard website package should not be represented as a formal security audit, penetration test or compliance certification unless that work is specifically performed by qualified parties.

Common Mistakes

1. Treating SSL as complete security.
2. Sharing one admin account.
3. Keeping former vendor access.
4. Trusting frontend validation.
5. Publishing production secrets.
6. Installing many security plugins without maintenance.
7. Backing up without testing restore.
8. Logging sensitive values.
9. Trusting hidden API routes.
10. Ignoring third-party scripts.
11. Using production customer data in demos.
12. Waiting for an incident before defining ownership.

FAQs

Is HTTPS enough for a business website?

No. HTTPS protects data in transit. It does not fix weak accounts, vulnerable software, broken permissions, unsafe forms or missing backups.

How often should a website be updated?

Review critical security updates promptly and maintain a regular update cycle. Test material changes before production when compatibility risk is significant.

Does a small website need backups?

Yes. Even a small site may depend on content, forms, configuration and domain settings. The backup scope and frequency should match business impact.

How can I stop form spam?

Combine server validation, rate limits, honeypots or challenges, request limits and monitoring. No single technique blocks every bot.

Is WordPress secure?

WordPress can be operated securely when core, plugins, themes, hosting, accounts and backups are maintained. Abandoned components and shared access increase risk.

Do I need a penetration test?

Riskier systems handling payments, sensitive data, multi-tenant access or critical operations may benefit from independent testing. Scope it according to architecture and business impact.

What should I do after a suspected breach?

Activate the incident plan, preserve evidence, restrict access carefully, rotate affected credentials, assess impact and involve qualified professionals. Avoid making untracked changes that destroy evidence.

Can security guarantee no attack will succeed?

No. Security reduces likelihood and impact through layered controls, monitoring, recovery and continuous improvement.

Related Guidance

• Secure admin login best practices
• Role-based access best practices
• Permission matrix template for web apps
• Website maintenance checklist
• Web application audit checklist

For a current business website or custom system, review web application development, software development and integrations. Share the system type, users, data sensitivity and required integrations through the contact page so security requirements can be scoped explicitly.