"We have strong
infrastructure." Did you
battle test it, or just put it on AWS?

When you test against a genuinely hardened target — a LVMH platform, a PayPal endpoint, a Robinhood API — you feel the difference immediately. Your first reconnaissance requests come back clean. Your second wave starts getting rate-limited before you have done anything that should trigger a rate limit. Your third attempt gets a CAPTCHA that you did not expect. By the fourth, you are getting blocked at the network edge before your request reaches the application layer at all.

That friction is deliberate. It is expensive to build and maintain. And it tells you everything about how seriously the organisation takes security — not from a policy document, not from a security certification, but from what happens when someone actually pushes against it.

Then you test a South African target and the contrast is jarring. Not because South African developers are less capable — they are not. But because the security investment decisions made by South African organisations consistently underweight the defensive layers that global enterprises treat as baseline. The tools exist. The pricing is accessible. The configuration knowledge is available. The implementation is simply not happening.

What "strong infrastructure" actually means — and what it does not

"We're on AWS" is the most common version of the "strong infrastructure" claim in South African business conversations. It is not wrong — AWS does provide a genuinely solid hosting foundation. But AWS provides infrastructure security, not application security. That distinction is the gap that attackers walk through.

AWS secures the physical data centres, the hypervisor layer, the network backbone, and the hardware. Everything above that — your application code, your authentication logic, your API endpoints, your database queries, your session management — is your responsibility. AWS calls this the Shared Responsibility Model. It is documented clearly. It is also widely misunderstood.

Putting your application on AWS does not make your application secure. It makes the server it runs on physically resilient. A SQL injection vulnerability in your application code is just as exploitable on AWS as it is on a shared hosting account. A misconfigured S3 bucket — one of the most common AWS security failures — leaks data regardless of how many security certifications AWS holds. The infrastructure is sound. The application is exposed.

What the hardened targets actually have — the full stack

When you test against a target like LVMH — which runs multiple distinct platform environments, each with different codebases and security postures — you build a picture of what layered defence actually looks like in practice. Here is what the hardened version of these stacks typically includes, from the edge inward:

DataDome — and why SA businesses that can afford it probably don't have it

DataDome is a bot management platform used by companies like LVMH, Foot Locker, Rakuten, and Reddit. It sits in front of your application and analyses every request using real-time machine learning — browser fingerprinting, behavioural biometrics, device reputation scoring — to determine whether the request comes from a human or a bot.

When you hit a DataDome-protected target during security research, you experience something specific: false positives that are clearly deliberate. Your browser session — a legitimate human browsing session — gets challenged or blocked because something in your behaviour pattern matched a bot signature. The timing between your page loads. The way your browser rendered a JavaScript challenge. The absence of a specific browser API that bots commonly omit.

That friction is the product working as designed. A system tuned to never produce false positives is a system tuned to let sophisticated bots through. DataDome accepts that legitimate users will occasionally be challenged — because the alternative is letting automated attacks through without friction.

DataDome starts at approximately $3,000 per month for enterprise deployments. For a South African retail bank, a major insurer, or a large e-commerce platform — organisations that process millions of rands in transactions monthly — that is a rounding error in the IT budget. The ROI calculation against a single successful credential stuffing attack that compromises thousands of customer accounts is not close.

The reason South African organisations at that scale typically do not have DataDome or equivalent is not cost. It is awareness and prioritisation. The IT team knows what it is. The security team may have requested it. The budget conversation did not happen because the board did not understand why bot management is different from the WAF they already have — and nobody made the case compellingly enough.

What SA businesses get for free and are not using properly

Before DataDome, before enterprise WAF, before anything paid — Cloudflare's free and Pro tiers provide a security baseline that most South African SMEs and a surprising number of larger organisations are not fully utilising. These are features that cost nothing or close to nothing, that take an afternoon to configure properly, and that block the majority of opportunistic attacks.

The last row in that table deserves its own paragraph. The single most common Cloudflare misconfiguration in South African organisations is exposing the origin server IP address through DNS records — usually a legacy A record for a subdomain like mail. or ftp. or direct. that was never proxied through Cloudflare.

Once an attacker has your origin IP, every protection Cloudflare provides can be bypassed by sending requests directly to that IP rather than through Cloudflare's edge. WAF — bypassed. Bot Fight Mode — bypassed. Rate limiting — bypassed. DDoS mitigation — bypassed. The entire defensive layer disappears because one DNS record was not proxied.

Finding your origin IP from your Cloudflare deployment takes about thirty seconds using historical DNS records, certificate transparency logs, or Shodan. Any competent attacker does this as the first step. Most South African organisations have not closed this gap.

Battle testing — what it actually means to know your infrastructure is solid

There is a meaningful difference between believing your infrastructure is secure and having tested it. Most South African organisations operate on belief. The ones that have been through a HackerOne or YesWeHack bug bounty programme, or have engaged a competent penetration testing firm for a genuine test rather than a compliance checkbox exercise, operate on verified confidence.

Battle testing means: someone who knows what they are doing has deliberately tried to break your security and reported what they found. Not a vulnerability scanner running automated checks against a OWASP list. Not a penetration test that stayed within a tightly scoped safe zone that excluded the most interesting attack surfaces. An actual attempt — within safe harbour — to find ways in.

The false positives from a system like DataDome are themselves a form of battle testing. When your own security team's legitimate browser sessions are getting challenged, it means the system is sensitive enough to catch behaviour that deviates from the human baseline. A system that never produces false positives during internal testing is a system calibrated for legibility, not security.

The question every South African CIO, IT manager, and business owner should be asking is this: the last time someone said our security is strong, what did they base that on? Was it an audit that tested the documentation? Was it a penetration test that covered a defined subset of the application? Was it a bug bounty programme where external researchers with real skill actually attempted to get in? Or was it a vendor assurance that the hosting provider's infrastructure is certified?

Those are four very different answers to the same question. Only one of them — the bug bounty programme or equivalent external adversarial testing — tells you what you actually need to know.