Website security
Website security is more than SSL: what a business owner should ask
The padlock in a browser is useful, but it is only one part of website security. The more important question is whether the right person can perform the right action on the right data—and whether the business can recover when something fails.
Identify the work that carries risk
Write down what would hurt the business: a customer seeing another customer’s documents, an unauthorised refund, a changed payout account, a lost booking or a leaked database. Use those scenarios to decide which controls and tests matter first.
This makes a security review more useful than counting plugins or badges. A public brochure page and an administration tool that can suspend customer services need different safeguards.
Check permission at the server
A hidden button is not an access-control system. The server must check the signed-in user and permission whenever protected data is read or changed. It should also check that the requested record belongs to the correct customer or organisation.
Use individual staff accounts and remove unnecessary privileges. Require fresh confirmation for high-impact actions such as changing a payment destination, exporting sensitive records or deleting a project. Keep a useful audit history of who authorised the action and what happened.
Protect the application’s inputs and credentials
Forms, uploads and APIs need validation appropriate to their purpose. File uploads should not become executable application code. Database queries, sessions and state-changing requests need suitable protections implemented and reviewed by the developer.
Keep secrets out of public source code, browser bundles and routine logs. Give each external integration only the access it needs. A single account with unrestricted access to every service increases the impact of one mistake.
Maintain and watch the system
Keep the application, dependencies and server supported. Use a firewall and rate limits as additional safeguards, not a substitute for correcting vulnerable application behaviour. Monitor important routes and delivery paths, including contact forms and email.
Agree who receives alerts and what they should do. Collect enough operational evidence to investigate problems while avoiding unnecessary retention of personal data or credentials in logs.
Test recovery and the release process
Keep protected backups and test a restore separately from production. Check that a software update can be rolled back without silently discarding newer transactions. A recovery plan needs both the application version and the corresponding data state.
Ask for a scoped review with findings, priorities and verification evidence. Security improves through maintained controls and repeatable checks; a single scan cannot promise that every possible vulnerability has been removed.
What a firewall can do—and what the application must do
A network firewall restricts exposed ports. A web application firewall can filter some suspicious HTTP requests and slow automated abuse. Neither proves that a logged-in person is allowed to open a particular invoice, file or admin action.
Test authorisation on the server for every sensitive action. A useful check is to try accessing one test account’s document from another test account and confirm that the server refuses it. Use controlled test data and authorised environments. OWASP’s guidance (opens in a new tab / नए टैब में) explains why permission checks must accompany authentication.
An owner-friendly monthly security review
Ask for evidence of five things: supported software, reviewed access, successful recovery testing, useful alerts and a rollback route for releases. A screenshot showing an active security plugin does not establish these outcomes.
Assign someone to respond to expiry notices, unusual login attempts and failed backups. Review public forms for rate limits, upload restrictions and unintended personal-data exposure. Keep payment handling with an appropriate payment provider, and avoid collecting information that the business does not need.
Reader conversation
Share your experience
What has worked for you, or what would you like to know about this topic?
1. Verify your email
Choose Send code to receive a verification email. Your email address stays private.
2. Write your comment
Verify your email before submitting a comment.
Reader comments