Website security essentials
for growing businesses

Website security can feel like a technical concern that belongs with developers or hosting providers.

In reality, it is a business responsibility.

A security incident can expose customer information, interrupt sales, damage search visibility and prevent employees from accessing important systems. For a growing company, even a short period of downtime can affect revenue and customer trust.

Security does not begin with an expensive penetration test or a long list of specialist tools. It begins with a reliable set of baseline protections covering the website, its users and the services connected to it. Our security service helps growing businesses apply those foundations.

Understand what you need to protect

A simple marketing website and a customer-facing web application do not carry the same level of risk.

A marketing website may contain:

• Contact and enquiry forms
• Analytics tools
• Advertising scripts
• Content management accounts
• Newsletter integrations
• Customer tracking data

A web application may also hold:

• Customer records
• Payment information
• Employee accounts
• Uploaded documents
• Private messages
• Commercially sensitive data
• API credentials
• Account permissions

Begin by documenting what information the website collects, where it is stored, who can access it and which external services receive it.

You cannot apply suitable protection if you do not understand what the system contains.

Use HTTPS across the entire website

Every website should use HTTPS, not only pages containing login or payment forms.

HTTPS encrypts information travelling between the visitor’s browser and the website. It helps prevent other parties from reading or altering that information while it is in transit.

OWASP recommends using properly configured TLS for web applications and requiring HTTPS for authenticated pages and APIs. OWASP Transport Layer Security guidance

Your website should:

• Automatically redirect HTTP traffic to HTTPS
• Use a valid and current certificate
• Avoid loading images or scripts through insecure connections
• Apply HTTPS to subdomains and APIs
• Use appropriate security settings such as HSTS

Certificates are now included with many reputable hosting services, so there is rarely a valid reason for a public website to operate without HTTPS.

Protect every administrative account

A website is only as secure as the accounts used to manage it.

Require multi-factor authentication for:

• Content management accounts
• Hosting providers
• Domain registrars
• Cloud services
• Source-code repositories
• Analytics platforms
• Email marketing tools
• Payment providers
• Administrative web-app accounts

Multi-factor authentication adds another verification step beyond the password. CISA includes MFA, logging and single sign-on among the protections that should be available in secure products by default. CISA Secure by Design Pledge

Each employee should have an individual account. Avoid shared administrator logins because they make it difficult to identify who made a change or remove access when someone leaves.

Access should also be reviewed regularly. Former employees, agencies and contractors should not retain access after their work ends.

Give users only the access they need

Not every employee needs full administrative control.

A marketing employee may need to publish articles but should not necessarily be able to install software, change payment settings or export every customer record.

Use roles and permissions to limit what each person can see and do.

This is known as the principle of least privilege. It reduces the potential damage caused by a compromised account or an accidental change.

Access control should also be enforced behind the interface. Hiding a button is not enough if a user can still reach the underlying page or API directly.

Broken access control remains the highest-ranked risk in the OWASP Top 10 for 2025, which identifies the most significant risks affecting web applications.

Keep software and dependencies current

Modern websites depend on many layers of software:

• Content management systems
• Plugins
• Themes
• Server software
• Programming frameworks
• Code libraries
• APIs
• Third-party scripts

Each dependency can introduce vulnerabilities.

Maintain a clear process for:

• Monitoring security updates
• Testing important updates
• Applying patches promptly
• Removing unused plugins and packages
• Replacing unsupported software
• Identifying vulnerable dependencies
• Recording who owns each system

Do not keep an old plugin simply because removing it might be inconvenient. Unused software creates risk without providing value.

Software supply-chain failures are now one of the leading categories in the OWASP Top 10. This reflects the importance of understanding and maintaining the external components on which a website depends. OWASP Top 10: 2025

Secure forms and user input

Every form, search box, upload tool and API endpoint is a place where information enters your system.

The application should treat this information as untrusted.

Developers should validate input, restrict what each field can accept and safely handle information before displaying it or sending it to a database.

This helps reduce risks such as:

• Malicious database queries
• Harmful scripts
• Unexpected file uploads
• Spam submissions
• Manipulated URLs
• Automated account creation

Validation must happen on the server, even if the browser also checks the form. Browser-side controls can improve usability, but they can be bypassed.

Public forms may also need rate limits, spam filtering or additional checks to prevent automated abuse.

Protect sensitive information

Do not collect information simply because it might become useful later.

The more sensitive data you retain, the greater the potential impact of a breach.

For every type of information, ask:

• Do we need to collect it?
• Where is it stored?
• Is it encrypted?
• Who can access it?
• How long should we retain it?
• When and how will it be deleted?
• Is it sent to another provider?
• Does it appear in application logs?

Passwords should never be stored as readable text. API keys and other secrets should not be placed directly in source code or exposed in browser files.

Sensitive information should also be excluded from error messages, URLs and routine logs.

Apply browser security protections

Web browsers support security controls that can reduce the risk of common attacks.

Appropriate HTTP security headers can help protect against problems such as malicious scripts, clickjacking and information exposure. OWASP describes security headers as a useful additional layer of website protection. OWASP HTTP Security Response Headers guidance

Important protections may include:

• Content Security Policy
• HTTP Strict Transport Security
• Controls over embedded pages
• Content-type protection
• Referrer restrictions
• Permissions policies

A Content Security Policy can restrict which scripts and external resources a browser is allowed to load. It is a second layer of protection rather than a substitute for secure development. OWASP Content Security Policy guidance

These settings should be tested before strict enforcement because an incorrect configuration can interfere with legitimate website features.

Review third-party scripts

Marketing websites often include code from several external providers:

• Analytics
• Advertising platforms
• Live chat
• Heatmaps
• Video players
• Scheduling tools
• Social media widgets
• Personalisation services

Each script runs within the customer’s browsing experience and may receive access to website activity or entered information.

Before adding a third-party tool, determine:

• What information it collects
• Whether it is genuinely required
• Which pages need it
• How frequently it is updated
• Whether the provider has a credible security process
• How it affects performance and privacy
• How quickly it can be removed

Keep a record of all third-party scripts and remove those no longer in use.

Back up the website and test restoration

A backup is useful only if it can be restored.

Maintain regular backups of:

• Website files
• Databases
• Uploaded documents
• Configuration
• Important content
• Infrastructure settings

Backups should not rely solely on the same account or environment as the live website. If an attacker compromises that account, they may also delete or alter the backups.

Decide how much data the business can afford to lose and how quickly the website needs to be restored. These answers should determine the backup frequency and recovery process.

Test restoration periodically. Discovering that a backup is incomplete during an incident is too late.

Monitor activity and configure alerts

Security incidents are more damaging when they remain unnoticed.

Web applications should record important events such as:

• Failed login attempts
• Password and email changes
• New administrator accounts
• Permission changes
• Unusual data exports
• Suspicious API activity
• Security setting changes
• Unexpected application errors

Logs need active monitoring or alerts. Collecting information that nobody reviews provides limited protection.

Avoid recording passwords, payment information or unnecessary personal data in logs. OWASP identifies inadequate logging and alerting as a major application security risk, while also warning that logs themselves can expose sensitive information if handled poorly. OWASP Security Logging and Alerting guidance

Prepare an incident response plan

Even well-protected websites can experience incidents.

A growing business should know what happens if:

• The website is defaced
• Customer information is exposed
• An administrator account is compromised
• The application becomes unavailable
• A third-party service is breached
• Malicious code is discovered
• Payment or contact details are redirected

The response plan should identify:

• Who has authority to act
• Which developer or provider should be contacted
• How the website can be taken offline safely
• How affected credentials will be changed
• Where clean backups are stored
• How customers will be informed
• Which legal or regulatory advice is required
• How evidence will be preserved
• How normal service will be restored

Keep essential contact and recovery information somewhere accessible even when the main systems are unavailable.

Test according to the level of risk

Automated scanning can identify common problems, but it cannot determine whether every business rule and permission is secure.

Testing may include:

• Dependency scanning
• Configuration reviews
• Access-control testing
• Code review
• Automated vulnerability scanning
• Penetration testing
• Backup restoration tests
• Incident response exercises

A public marketing site with no customer accounts requires a different testing programme from a web application processing payments or storing sensitive records.

Testing should reflect the potential impact of a failure.

Make security part of every change

Security is not a one-time project completed when the website launches.

Every new integration, form, user role and feature can alter the risk.

Include security in the normal development process:

1. Identify what information the feature will use.
2. Consider how it could be misused.
3. Define permissions and secure defaults.
4. Review external dependencies.
5. Test normal and unexpected behaviour.
6. Record security-relevant activity.
7. Monitor the feature after release.

This is more effective than attempting to add security after a system has already been designed and built.

A practical website security checklist

Every growing business should be able to confirm that:

• HTTPS is enforced across the website and APIs.
• Multi-factor authentication protects administrative accounts.
• Each user has an individual account.
• Permissions follow the principle of least privilege.
• Former employees and suppliers lose access promptly.
• Software, plugins and dependencies are regularly updated.
• Unused components and accounts are removed.
• Forms and uploads are validated securely.
• Sensitive information is encrypted and retained only when necessary.
• Passwords and API keys are handled securely.
• Appropriate browser security headers are enabled.
• Third-party scripts are documented and reviewed.
• Backups are maintained and restoration is tested.
• Important security events create useful alerts.
• An incident response plan exists.
• Security testing reflects the website’s actual level of risk.

Security is part of customer trust

Website security is not only about preventing sophisticated attacks. It is about consistently applying sensible protections to accounts, data, software and business processes.

The basics matter.

Use HTTPS. Protect accounts with multi-factor authentication. Keep software current. Limit access. Maintain tested backups. Monitor important activity and know how the business will respond when something goes wrong.

These controls will not eliminate every risk, but they provide the foundation every credible marketing website and web application should have in place.