Web security: how we approach it as an agency.

Start with the data, then assign responsibility

A public company website and a customer portal holding contracts and personal documents need different levels of scrutiny. What matters is the data involved, who can access it and what happens if the application fails or someone misuses that access.

We start with practical questions. Which information needs protection? Who may read it, and who may change it? Which integrations connect the website to other systems? What stops working in the business when the application is unavailable?

The answers help define the responsibilities. A provider might maintain the operating system and database, we might update the application, and the client might approve new user accounts. The actual arrangement depends on the service and our brief. We document it, including the people to contact and how to report a problem.

Hosting: the client keeps control

Performance and cost are only part of choosing a hosting or cloud provider. We also look at supported software versions, backup procedures, access controls and incident handling, alongside data location and contractual requirements. A data centre in Europe does not, by itself, settle who fixes a misconfigured application.

We do not run our own client hosting infrastructure or earn commission on hosting contracts. Clients contract directly with providers. We advise on the choice and work with everyone involved to agree the technical setup. Accounts and data should remain under the client’s control, even if the working relationship changes.

During setup, we look at which services are reachable and what permissions they have. A database does not need to be publicly accessible just because the website is. Test environments need access protection, and copying live customer data into development requires a considered decision, not a convenient shortcut.

Containers make it possible to package and run an application and its components consistently. Keeping that environment secure still requires maintained base images, limited process privileges and controlled network connections. The container runtime and underlying operating system need maintenance too.

Choose software you can keep maintaining

Choosing a CMS or framework means thinking about how the application will be maintained five years from now. We look for clear security advisories, supported releases, available fixes and a realistic upgrade path. TYPO3, for example, has a dedicated Security Team publishing advisories for the core and extensions. Libraries and runtimes such as PHP or Node.js deserve the same attention.

One small library can bring in other packages nobody on the project selected individually. They are still part of the software we depend on. Automated checks can find known vulnerabilities in those dependencies. Assessing a finding takes more work: is the affected version in use, can the vulnerable function be reached, and is a fix available? Sometimes the appropriate response is to disable a feature temporarily.

Frameworks provide tools for checking permissions. We still have to define and test the application’s rules. Being signed in to a customer portal must not be enough to download any document in it. On every request, the application needs to check whether this person may access this document. Hiding a link in the interface does not enforce that rule.

Credentials: where are they, and what can they do?

Passwords, API keys and access tokens raise two separate questions: how are they stored, and what could someone do with them?

An encrypted key can still grant far too much access. An integration that reads product data does not need permission to manage users or delete orders. Least privilege means granting only what the task requires. It limits the damage if a credential is compromised.

Secrets management covers how credentials are supplied securely, replaced when needed and revoked. Plaintext secrets do not belong in source code, container images or diagnostic logs. A private code repository is not a vault either. For people, we use individual accounts rather than shared logins, multi-factor authentication and a review of access when a task or working relationship ends.

CI/CD: know what shipped and how to recover

For automated releases, we use CI/CD pipelines to build software from source, run checks and produce an identifiable version for deployment. Release records show which tested version went live and what changed. The principle is the same on a cloud platform and a conventional server.

We choose the security checks to suit the application. They can include scanning libraries and container images for known vulnerabilities, checking for accidentally committed credentials and flagging potentially unsafe code. Someone must assess the results. A green pipeline means the agreed release criteria have been met. It does not mean the application has no security problems.

The pipeline itself usually has permissions that can change production systems. We protect it through approvals, limited access and isolated execution environments. Code from an unreviewed external contribution must not receive production credentials.

A release plan also needs a recovery plan. Restoring the previous code does not undo a database change. We work through those dependencies before making the change. Our article on moving TYPO3 to the cloud explains how this shapes a migration.

OWASP: understand the risks, define the checks

OWASP publishes freely available guidance and verification criteria for application security. Its Top 10 introduces the major categories of risk. It is too broad to serve as a detailed test checklist, and it is not a quality seal for a website.

The Application Security Verification Standard, or ASVS, provides requirements that can be checked. It helps define what to test in authentication, sessions, permissions and data handling, with a scope appropriate to the application and its risks. “Tested” should come with specifics: which areas, which version and against which criteria?

Independent security testing

Whether a project needs an independent penetration test depends on the application, its risks and the client’s requirements. Security specialists examine the agreed systems from an attacker’s perspective. The objectives, scope, timing and approach are agreed beforehand: a web application, its APIs or selected parts of the infrastructure, for example.

We have had good experiences with bugshell on penetration tests. What matters to us is that findings are clearly documented, can be discussed with the developers and can be checked again after a fix. That is how “changed” becomes “verified as fixed”.

A penetration test assesses a defined scope at a particular point in time. New features, changed permissions or additional integrations can justify another test. We agree the scope and timing to suit the project. Testing does not replace ongoing maintenance.

Operations: updates, monitoring and recovery

Within an ongoing support agreement, we review updates and security advisories for the systems and extensions covered. We test changes in a separate environment before deployment, including important functions and integrations. Major version upgrades usually need additional work and are planned separately.

Monitoring needs to reflect how the application is used. A homepage that loads tells you nothing about whether sign-in, data imports or form submissions work. The operating agreement defines which availability measures, errors and security events are monitored, and who responds. Logs themselves need protection and should not collect unnecessarily sensitive content.

Recovery is a procedure to rehearse, not a checkbox marked “backup available”. Restoring a backup is how you find out whether the files and database are consistent, whether the restore works and how much data could be lost. After a security incident, the cause also needs investigating. Otherwise, restoring service may simply put the same vulnerability back online.

We agree contact arrangements, reporting procedures and response times to suit the system. A maintenance agreement does not automatically include round-the-clock support. Nor does starting work on an incident promise a resolution by a particular time. Our website maintenance and support page explains the approach.

AI speeds up attacks. It does not remove the need for review.

AI helps attackers analyse information, look for vulnerabilities and adapt attack code. The UK’s National Cyber Security Centre expects more efficient attacks and greater pressure on poorly maintained systems as a result. In its 2025 assessment, it judged fully automated, end-to-end advanced cyberattacks unlikely by 2027. It also expected AI to further shorten the time between a vulnerability becoming known and being exploited. Prompt assessment and patching of known weaknesses become more important, not less.

On the development side, access matters just as much. A coding agent can change files, install dependencies and execute commands to the extent its environment allows. Deciding which data, tools and systems it may use is part of deciding to use it at all. Producing a code suggestion does not require production credentials.

An AI feature inside an application brings another risk. External documents or messages can contain instructions intended to divert the model from its task. These prompt-injection attempts need to be considered wherever the system reads data or can take action. The application must enforce permissions independently of the model.

Where code comes from does not change the review it needs. A plausible suggestion still has to fit the architecture, respect the intended permissions and be testable. That applies whether a person wrote it or an AI generated it.

Give people the knowledge their role requires

Training should reflect the work people actually do. Developers need secure implementation and testing practices. Editors need clarity on roles, approvals and data handling. Administrators also need account-management skills and an eye for unusual access requests. When an error keeps recurring, we work through the cause and the remedy with the team.

We stand behind our technical recommendations, including when they mean more work. We explain what is urgent, which measures are proportionate and where additional specialists are needed. Together with the client, we make informed decisions about the work, responsibilities and remaining risks. We will not support a decision to knowingly ignore security problems.

For a new project, we establish the requirements. For an existing website, we also assess its current state and the work still to be done.