Platform Engineering

Website security, and the search consequences of failing it

A compromise is not only a security incident. It is a visibility one: a safety flag, a malware warning or a suspension removes a site from search far more completely than any code change could. The two have to be engineered together.

The problem

Security failures are discovered through search, not through monitoring

Most site owners learn they have a security problem when traffic falls, when a browser warning appears, or when a search engine marks the domain. By then the site has been flagged, and the recovery involves restoring reputation with third parties as well as fixing the original fault. The window between compromise and discovery is what determines how expensive it becomes.

  • A browser, antivirus or firewall warning about the domain
  • Traffic that fell sharply with no change to content or configuration
  • Unexpected outbound requests, injected content or unfamiliar files
  • Attack traffic large enough to affect availability
  • Search results showing a warning, or the domain suppressed entirely
  • No record of what changed, so the entry point cannot be identified
  • Third-party security products disagreeing, with only some flagging the domain
Who this is for

The people who usually bring us this problem

CTO / VP Engineering

You have a public platform to defend and need prioritised, practical hardening rather than a compliance-shaped checklist.

Head of Platform / Infrastructure

You are absorbing attack traffic or recovering from a compromise and need the entry point identified rather than the symptoms cleared.

Head of Digital / Marketing

Organic traffic has collapsed and the cause may be a safety flag rather than a ranking change. You need to know which, quickly.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

A safety flag removes a site from search more completely than any ranking change

Being marked unsafe is not a decline in position; it is removal from consideration, with a browser warning in front of anyone who arrives anyway. Recovery requires the underlying fault to be fixed and the flag to be cleared with each vendor separately.

Attack traffic and availability are the same conversation

Volume aimed at taking a site down and volume aimed at exploiting it arrive the same way. Capacity planning that ignores hostile traffic underestimates the requirement.

Unidentified root cause means recurrence

Cleaning injected content without establishing how it got there leaves the entry point open. The same compromise returns, usually quickly, and each recurrence costs another recovery cycle.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Attack surface review and hardening

Where a public platform is exposed — application versions, admin paths, upload handling, third-party integrations, credential practice — prioritised by exploitability rather than by checklist length.

Attack traffic mitigation

Absorbing hostile traffic without blocking legitimate users: rate limiting, filtering, caching strategy and edge protection sized against what the platform actually receives.

Compromise investigation

Establishing the entry point rather than clearing the symptom — what changed, when, how, and what else it touched. This is the step that determines whether the incident is over.

Malware and injected content removal

Removing injected content including in generated artefacts not tracked in version control, which is where it survives an otherwise complete cleanup.

Safety-flag remediation

Identifying which security vendors have flagged the domain, supplying the evidence each requires, and confirming clearance per vendor — because they do not clear in step with one another.

Search recovery after compromise

Re-establishing crawl and indexation once the flag is clear, including reconsideration requests where required and verification that traffic returns.

Monitoring and response readiness

Detecting change on the public surface — new files, altered responses, unexpected redirects — so the next incident is found by monitoring rather than by a customer.

Dependency and plugin hygiene

Establishing what is installed, which components are receiving security updates, which have been abandoned upstream, and which are duplicated. Most compromises begin with a component that was knowably out of date, so this is the most common finding rather than the least.

Access and administrative controls

Who can reach the application's administrative surface, through what, and with what privilege — replacing shared credentials, dormant accounts and undocumented access with named access that can be revoked. On a public platform this is usually the shortest path between an attacker and everything else.

Backup and restore testing

Confirming that backups exist, that they complete, and that a restore actually works. An untested backup is a routine rather than a recovery capability, and the difference is discovered at the worst possible moment.

Edge protection where it helps

WAF-equivalent filtering, rate limiting and CDN configuration sized to the attack patterns the platform actually receives. Useful as one layer and not a substitute for the application fixes below it — an edge rule does not compensate for an unpatched component or a reused credential.

Remediation handoff

A defect report precise enough for another team to act on, with the order of work, an owner for each item and the criteria that will show it is fixed. On most of these engagements a large part of the value is that document rather than our own hands on the code.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

  1. Treat the visibility consequence as part of the incident

    A compromise and a safety flag are one event with two recoveries, and they are sequenced: the fault is fixed, then the flag is cleared, then search performance is restored and verified. Handling them as separate workstreams is how sites stay flagged after being cleaned.

  2. Find the entry point before removing anything

    Clearing injected content first destroys the evidence that would identify how it got in. The investigation happens before the cleanup, even under pressure, because the alternative is doing it twice.

  3. Assume the artefacts as well as the source

    Injected content frequently survives in compiled output, caches, upload directories and generated files that are not in version control. Anywhere the application writes is checked, not only the repository.

  4. Harden by exploitability, not by list length

    The realistic attack paths are addressed first. A long checklist of low-relevance items provides comfort rather than protection, and it delays the changes that would actually have prevented the incident.

  5. Clear flags vendor by vendor

    Different security products maintain independent assessments and clear independently. Each is checked and evidenced separately, because a site can appear clean in one browser and flagged in another.

  6. Verify recovery in search, not only in security tools

    The incident is closed when crawl and impressions have recovered, not when the warning disappears. Those are different events and the second lags the first by weeks.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Assessment output

  • A risk register: every finding, with its exploitability and its business consequence
  • Remediation order — what to fix first, and why that order rather than another
  • A named owner for each item: ours, yours, or a third party's
  • Verification criteria, so 'done' is a checkable statement rather than an opinion
  • Explicit statement of what was not assessed

Remediation

  • Entry-point identification and closure where a compromise has occurred
  • Malware and injected content removal, including generated artefacts
  • Credential rotation and access review
  • Hardening of the identified attack paths
  • Edge filtering and rate limiting where applicable
  • Dependency and version currency work

Ongoing protection, if retained

  • A maintenance cadence agreed by contract, not implied
  • Patch and version currency tracked rather than reactive
  • Public-surface change monitoring
  • Periodic access review
  • Recurring written report of what was found and what changed
  • Escalation path for anything outside the agreed scope

Recovery, where a flag exists

  • Per-vendor flag clearance with supplied evidence
  • Search reconsideration and indexation recovery
  • Crawl and traffic verification against pre-incident baseline
Under the hood

Architecture and technology

Protection

  • Edge filtering and rate limiting
  • WAF-equivalent rules sized to observed attack patterns
  • Admin and authentication surface restriction
  • Upload and input handling
  • Dependency and platform version currency

Detection and recovery

  • File-integrity monitoring over the public surface
  • Backup retention and tested restore
  • Access and change auditing
  • Vendor flag monitoring
  • Crawl and error-rate alerting as a compromise signal
Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions
Online communities

Arrse.co.uk

An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.

4%increase in organic clicks
Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

Availability rather than security

Attack traffic usually involves both, and they are separated here by whether the goal is staying up or staying clean.

Platform reliability and availability

Traffic fell and no flag is present

A compromise is one cause of impression loss among several, and the log evidence distinguishes them.

Crawl and indexation diagnosis
Questions

Frequently asked

Do you secure the application, the server, or both?

Both, and the split matters because they fail differently. The application layer is where an attacker gets in — an unpatched component, an exposed administrative path, an input handler that accepts more than it should. The server layer is where the consequences multiply — unnecessary services, permissive file ownership, credentials readable by the wrong process. An assessment that covers one and not the other leaves the more convenient route open, so the exposure review covers the application and the environment it runs on together.

What will we receive after the assessment?

A risk register rather than a score. Each finding carries its exploitability, the business consequence, the order it should be fixed in, who owns it, and the criteria that will show it is resolved. You also get an explicit statement of what was not assessed, because a security review that implies total coverage when it covered part of the estate is more dangerous than one that states its limits. Where the work then proceeds, the same document becomes the remediation plan.

Can you work with our hosting provider?

Yes, and on shared or managed hosting it is frequently necessary — some of what an assessment finds can only be changed at a layer the provider controls, such as edge filtering, server configuration or platform versions. Where that is the case the finding names the provider as the owner rather than leaving it unassigned, and we will supply the specifics needed to raise it with them. We do not resell hosting, so there is no reason for us to prefer one arrangement over another.

We have been flagged as unsafe. How long until traffic returns?

Vendor clearance typically takes days to a few weeks and varies by vendor, because they assess independently and clear independently. Search recovery lags that — crawl and impressions return over weeks after clearance, not immediately, because the search engine has to observe the change. We will not give you a precise date, but we will set the sequence and measure against it.

Do you provide ongoing security monitoring?

We set up monitoring over the public surface — file integrity, unexpected redirects and altered responses — which catches the compromise patterns that affect a website. We do not offer a managed security operations service, and if what you need is continuous SOC coverage that is a different engagement with a different provider.

Can you guarantee we will not be attacked again?

No, and nobody can. What can be done is closing the entry point that was used, hardening the paths most likely to be tried next, and making a recurrence detectable within hours rather than discovered by a customer. The second and third of those matter more than they sound, because most repeat compromises are the same entry point left open.

Is a WAF enough?

It is one layer and rarely sufficient on its own. A WAF filters requests it recognises as hostile; it does not compensate for an unpatched application, an exposed admin path, or credentials that were reused. Those are the routes most compromises actually take, and edge filtering does not address them.

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.