Application security, in plain English.

When an attacker gains control of a legitimate user’s account, typically through credential stuffing, phishing, malware or a stolen session, and then acts as that user.

For banks and wallets, takeover is where application security meets fraud. I look at the whole chain: bot controls on login and OTP, step-up checks on new payees, and whether the SOC and the fraud team see the same signals.

Building an inventory of the APIs an organisation actually exposes, from live traffic, gateways, code and specifications, so undocumented endpoints can be found and protected.

Most WAAP platforms can learn API endpoints from live traffic. I use that during the monitoring period of a migration, then compare it with what the development teams believe they published. The difference is the shadow API list.

A service in front of APIs that handles routing, authentication, rate limiting, quotas and versioning, giving one controlled entry point for API traffic.

A gateway is good at checking that a token is valid. It rarely knows whether that user may read that specific account. Teams that treat the gateway as their API security programme often still have object-level authorisation gaps behind it.

Protecting application programming interfaces (APIs) from misuse: knowing every API you expose, authenticating callers, authorising every object and function, and limiting abuse.

APIs carry the data that web and mobile front ends display, so that is where attackers go. I start with the inventory, then test authorisation with two accounts and swapped IDs, because the most damaging API flaws look like valid requests.

Platform services, such as Google Play Integrity API and Apple App Attest, that let a backend verify a request comes from a genuine, unmodified app on a genuine device.

Attestation complements app shielding well: shielding defends the app on the device, attestation lets the server decide whether to trust the caller at all. The verdict has to be checked on the backend, or it protects nothing.

Decompiling a legitimate mobile app, adding malicious code, re-signing it and distributing the clone through links, messaging apps or third-party stores to steal credentials.

Integrity checks that stop a modified copy from running are the main in-app defence. Backend attestation and fast takedown requests cover the rest. A rise in repackaging detections should trigger customer communication, not just a ticket.

Protections added to a mobile app to make it harder to analyse, modify or manipulate: obfuscation, integrity checks, and runtime detection of rooting, hooking and debuggers.

Shielding raises the cost of attacking the device side. It does not fix weak API authorisation, because an attacker does not have to use your app. I helped roll out Zimperium in-app protection for a leading private bank’s app, including policy tuning and SDK conflicts.

The practice of finding, fixing and preventing security weaknesses in software across its life, from design and code to deployment and operation, covering web apps, APIs and mobile apps.

I assess it in six areas: edge and WAAP, APIs, vulnerabilities and exposure, monitoring, mobile apps, and governance. Tools matter, but many of the gaps I find are about ownership: findings without owners, controls nobody tuned, logs nobody reads.

Mapping how an attacker could chain individual weaknesses, such as an exposed service, a misconfiguration and reusable credentials, into a route to a critical system.

It changes the priority list. A medium-severity flaw on an exposed server that leads to privileged credentials should outrank an isolated critical finding on a system nothing can reach. Automated penetration testing platforms such as RidgeBot help show these chains with evidence.

Continuous discovery and monitoring of an organisation’s internet-facing assets, such as domains, IP addresses, certificates, cloud services and APIs, as an attacker would see them.

The value is in what you did not know you had: a forgotten subdomain, an old origin still answering, a test API left online. Certificate transparency logs and historical DNS make these easy for attackers to find, so they should be easy for you too.

In a data pipeline, the build-up that occurs when a downstream stage cannot keep up, forcing earlier stages to slow down, queue events or, once buffers run out, drop them.

I resolved backpressure in a pipeline sending F5 WAAP logs through Logstash into a bank’s Trellix SIEM. The hard part was not parsing. My lessons: size for attack-day peaks, use persistent queues where the design allows, and monitor the pipeline itself.

Identifying automated traffic and deciding how to treat it: allowing good bots such as search crawlers, and challenging, slowing or blocking bad ones such as scrapers and credential stuffers.

Bot rules work best attached to business flows: login, OTP requests, registration, password reset. Start in monitoring mode and list the automation you want to keep. Browser challenges do not run inside native mobile apps, which usually need the vendor’s mobile SDK.

An API flaw where a user can call a function they should not have, such as an administrative action, because the server does not check the caller’s role for that operation.

It is listed in the OWASP API Security Top 10 2023. I test it by replaying privileged calls with an ordinary user’s token and by changing the HTTP method, for example from GET to DELETE. Predictable admin paths make it easy to find.

An API flaw where the server returns or changes a data object, such as an account or order, without checking the caller may access that specific object. Also known as IDOR.

It is first in the OWASP API Security Top 10 2023. A valid user changes an ID in a request and reads someone else’s data. The request looks normal, so a WAAP rarely catches it. It has to be fixed in code, by checking ownership on every request.

A public list, maintained by the US Cybersecurity and Infrastructure Security Agency (CISA), of vulnerabilities with reliable evidence of active exploitation in the wild.

If a finding is in KEV and the asset is reachable, it goes to the top of my list whatever its CVSS score. US federal civilian agencies must fix listed entries by set deadlines; everyone else can use it as a free, well-maintained exploitation signal.

Transforming an app’s code so it runs the same but is much harder to read and reverse engineer, for example by renaming symbols, encrypting strings and scrambling control flow.

Obfuscation raises the effort; it does not make anything secret. Keys and credentials inside an app should be treated as public whatever protection is applied. Keep the mapping files for every release, or your crash reports become unreadable.

An open standard maintained by FIRST (the Forum of Incident Response and Security Teams) that rates a vulnerability’s technical severity from 0.0 to 10.0. Version 4.0 was published in 2023.

A base score measures severity, not risk, and FIRST says so itself. Sorting a scanner export by CVSS produces a long list nobody can finish. I add exploitation evidence from EPSS and KEV, reachability, asset criticality and existing controls.

A distributed network of edge servers that caches and delivers web content from locations close to users, reducing load on origin servers and absorbing traffic spikes.

Many cloud WAAP platforms run on the same edge network as a CDN, so security inspection and caching happen in one place. Caching rules still need review: a cached page that contains one customer’s data can be served to the next.

A programme approach described by Gartner that reduces exposure to attack on a repeating cycle of five stages: scoping, discovery, prioritisation, validation and mobilisation.

Its value for lean teams is focus: fix fewer things, but the right ones, and be able to say why. Programmes most often stall at mobilisation, where every confirmed exposure needs a named owner, a deadline and a route into normal change management.

An automated attack that replays username and password pairs leaked from other breaches against a login page or API, relying on the fact that many people reuse passwords.

Stuffing traffic is spread across many IP addresses and looks like ordinary logins, so IP blocking alone fails. I look for bot management on login and OTP endpoints, breached-password checks, multi-factor authentication and a SIEM rule for failure spikes.

Vulnerability scanning in which the scanner logs in to each host with supplied credentials, so it reads installed software, patch levels and configuration instead of guessing from outside.

Credentialed scans see far more than unauthenticated ones, but a failed login quietly downgrades the result. On a Tier-1 bank programme, much of the effort went into scan credentials and authentication handling. Track authentication success per scan, not just completion.

A flaw that lets an attacker inject script into pages viewed by other users, where it runs in their browsers to steal sessions, capture input or act on their behalf.

The fix belongs in the application: context-aware output encoding, a framework that escapes by default, and a Content Security Policy as a second layer. A WAF blocks common payloads, which buys time, but encoding is what closes it.

Designing security as several independent layers of control, so that when one fails or is bypassed, another still stops or detects the attack.

The useful question is which layer stops each attack, and which only detects it. A WAAP does not fix object-level authorisation, and app shielding does not protect an API called from a script. The Attack Simulator on this site maps those layers.

Building security into DevOps delivery, so checks such as SAST, SCA, secrets scanning and policy gates run automatically in the pipeline and teams share responsibility for fixes.

A pipeline full of scanners is not DevSecOps if nobody triages the output. I look at what happens after a finding: who sees it, how fast it is fixed, and whether a failed gate can block a release or is quietly bypassed.

An attack that floods a service with traffic from many sources to make it unavailable. It can target network capacity or, at the application layer, expensive pages and API calls.

Network floods are largely a capacity problem for the provider. Application-layer floods are harder, because each request looks legitimate. Rate limits, bot controls and caching on expensive endpoints matter more there, and so does a runbook tested with the provider.

Testing a running application from the outside by sending crafted requests and analysing the responses, to find flaws such as injection, misconfiguration and weak session handling.

DAST only tests what it can reach. A scanner stuck at the login page reports a clean result for an application it never saw, so authenticated scanning that survives timeouts and multi-factor authentication is the first thing I check.

A model published by FIRST that estimates the probability, from 0 to 1, that a published vulnerability (CVE) will be exploited in the wild within the next 30 days.

EPSS answers a different question from CVSS: not how bad it would be, but how likely it is to be used. I use both, plus KEV status, and weight them by whether the asset is reachable and how critical it is to the business.

An alert or finding that flags legitimate activity or code as malicious or vulnerable, such as a WAF blocking a valid form submission or a scanner reporting a flaw that is not there.

In WAF tuning, false positives cluster in rich-text editors, JSON bodies, Base64 payloads, long cookies and names with apostrophes. The fix is almost never to switch a signature off. Scope each exception to one signature, one parameter and one path.

The chain of components that collects, parses, enriches, buffers and forwards logs from their sources to a SIEM or data store, for example agents or syslog feeding Logstash.

A stalled pipeline looks exactly like a quiet day. I check that throughput, queue depth and lag are monitored, that parsing failures are counted, and that someone is alerted when a critical source goes silent.

The average time between a vulnerability or exposure being found and being fixed and verified. In operations, MTTR can also mean mean time to repair or to recover.

I prefer the median for validated, high-priority exposures, because a few ancient findings distort an average. Report it by business service and by owner, not by tool, so the conversation is about who needs help.

A form of TLS in which both sides present certificates, so the server verifies the client as well as the client verifying the server. Common for partner APIs and edge-to-origin links.

Between a WAAP and the origin, mTLS proves a request came through your edge, not just through any customer of the same provider. With partners it is also a migration risk: their client certificates must work at the new edge before cutover.

A US National Institute of Standards and Technology framework for managing cybersecurity risk. Version 2.0 (2024) has six functions: Govern, Identify, Protect, Detect, Respond and Recover.

Govern, added in 2.0, is where boards look. I map OWASP SAMM results to it so application security shows up as part of enterprise risk governance rather than a technical silo. That mapping is my working method, not an official crosswalk.

Making sure origin servers accept traffic only after it has passed through the WAAP or CDN, so attackers cannot bypass edge protection by connecting to the origin directly.

An application behind a WAAP that still answers direct requests has not really been migrated. I look for three things: an origin allowlist of the provider’s ranges, a second check such as mTLS or a secret header, and no old DNS records pointing at the origin.

An OWASP awareness list of the most critical API security risks. The 2023 edition is led by broken object level authorisation and includes server-side request forgery.

Several of its risks are logic flaws a WAAP cannot see, because the malicious request is a valid one. I use it as a lens for testing and design reviews, not as a compliance checklist. Improper inventory management is the risk discovery tools help with most.

The OWASP standard for mobile app security, grouping requirements into control groups for storage, cryptography, authentication, network, platform, code, resilience and privacy.

App shielding mainly addresses MASVS-RESILIENCE. The other groups depend on how the app and its backend are built, so shielding cannot make an app compliant on its own. Its companion, the OWASP MASTG, describes how to test each control.

An open OWASP model for measuring and improving software security practices. Version 2 has five business functions with three practices each, scored on maturity levels from 0 to 3.

I score only against evidence: a secure coding standard nobody can show being applied counts as a document, not a practice. Report per practice rather than as one average, and aim for level 1 everywhere before pushing a few practices to level 2.

An awareness document from OWASP (the Open Worldwide Application Security Project) ranking the most critical web application risks, such as broken access control and injection.

It is a good starting point for training and test scope, and a poor definition of done. Passing a Top 10 scan says little about business logic flaws, and APIs have their own list: the OWASP API Security Top 10.

An authorised, simulated attack in which skilled testers find and exploit weaknesses in a system to show what an attacker could actually achieve, within an agreed scope and rules.

A good report shows impact and the path to it, not a rerun of scanner output. I ask for authenticated testing at each user role, business logic in scope, and a retest of fixes. An annual test describes one point in time.

A security approach that defines what valid traffic looks like and blocks everything else, as opposed to a negative model that blocks known attack patterns and allows the rest.

API schemas make a positive model practical: reject unknown fields, wrong types and oversized values before they reach code. It needs an accurate, current specification, otherwise it blocks legitimate change and teams switch it off.

Capping how many requests a client, token, IP address or account can make to an endpoint in a given time, to slow brute force, scraping and resource exhaustion.

Limits by IP address alone fail against distributed bots and can punish customers behind shared mobile carrier addresses. I prefer limits per account, token and endpoint, with tighter ones on costly actions such as sending an SMS one-time password.

Checks inside a mobile app that detect whether the device’s operating system restrictions have been removed (rooted Android or jailbroken iOS), which weakens the app sandbox.

Detection is a contest with root-hiding tools, so I treat it as a risk signal rather than a verdict. Whether to block, restrict high-risk actions or just report is a business decision, best made with real device telemetry from a report-only phase.

Security built into an application that detects and responds to attacks while it runs. In mobile apps it detects rooted devices, hooking, debuggers, emulators and tampering.

RASP and a WAF protect opposite ends of the same transaction: the app on the device and the servers behind it. I roll policies out in report-only mode first, then enforce the highest-confidence detections, such as active hooking during a transaction.

Intercepting and changing an app’s functions while it runs, using frameworks such as Frida, to skip security checks, alter values or capture data before it is encrypted.

On a banking app, hooking during a transaction is the detection I would enforce first: it is high-risk and high-confidence. The backend must still validate every amount and payee, because hooking can change what the app sends.

Checking each API request, and ideally each response, against its specification, such as an OpenAPI document, and rejecting unexpected fields, types, formats or sizes.

It stops malformed input and mass assignment early, and it is a good use of a WAAP or gateway. It does not stop broken object level authorisation, because a request for someone else’s account is perfectly well formed.

Developers or engineers inside delivery teams who take on a defined security role, acting as the first point of contact for security questions, with training and time set aside for it.

Champion programmes fail when the role is unrecognised extra work. I look for named champions, protected time, a regular forum with the security team, and a clear scope, such as triaging scanner findings and joining threat modelling sessions.

A platform that collects, normalises, stores and correlates logs and events from many sources to detect threats, support investigations and meet retention requirements.

Application attacks are often invisible to a SIEM because WAAP, API and application logs were never connected. I check coverage source by source, then whether detections exist for application attacks such as credential stuffing and object enumeration.

The team, processes and tools that monitor an organisation’s systems, detect and investigate security incidents and coordinate the response, in-house or as a managed service.

A SOC can only act on what it sees and owns. For applications that means agreed fields and use cases before a source goes live, a named contact in each application team, and a clear split with the fraud team for transaction alerts.

A flaw that lets an attacker make a server send requests to destinations of their choosing, such as internal services or cloud metadata endpoints, often via a URL the server fetches.

It appears in the OWASP API Security Top 10 2023 because webhooks, URL previews and file imports are common in APIs. The defence is an allowlist of destinations, blocked internal ranges, and cloud metadata services that require session tokens.

An API that is live in production but missing from the organisation’s inventory, such as an undocumented endpoint, a forgotten test service or an old version never retired.

Shadow APIs usually sit outside the controls added later: no schema, weaker authentication, no logging. I find them by comparing endpoints seen in WAAP or gateway traffic, and in the mobile app, against what teams believe they published.

A machine-readable inventory of the components, libraries and versions inside a piece of software, usually in SPDX or CycloneDX format.

Its practical value shows on the day a new library flaw is announced: with SBOMs, finding which applications are affected becomes a search rather than a round of emails. Ask software vendors for one with each release.

Tooling that identifies the open-source and third-party components in an application and flags those with known vulnerabilities or licence issues.

SCA output is noisy without exploit and exposure context. I prioritise components with KEV entries or high EPSS scores in internet-facing applications, and I check that someone owns upgrading them, not just reporting them.

A flaw where input supplied by a user changes the structure of a database query, letting an attacker read, change or delete data, or bypass authentication.

Parameterised queries fix it at the root. A WAF blocks many common payloads and is a useful virtual patch while the code is fixed. Scanners and SAST find many instances, so a live SQL injection usually points to a testing gap as well.

Analysing source code, bytecode or binaries without running them to find security flaws, such as injection or insecure cryptography, early in development.

I have deployed SAST and DAST with Veracode. The tool is the easy part; triage is the work. Without someone tuning rules and confirming findings, developers soon learn to ignore the results.

A structured way to examine a system’s design, work out what could go wrong and decide on mitigations before it is built or changed. STRIDE is a widely used method.

Four questions carry most of the value: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job? I run it on significant changes, not every ticket, and keep the output short enough to be read.

The point where an encrypted TLS connection is decrypted. A WAAP terminates TLS at its edge to inspect traffic, then usually opens a new encrypted connection to the origin.

That gives two connections where there was one, and each fails differently: old partner clients on the front, origins with weak ciphers or broken chains on the back. I test both legs for every application before any DNS change.

A WAF or WAAP rule that blocks attempts to exploit a specific known vulnerability, protecting the application until the code or component can be fixed.

A virtual patch buys time; it is not a fix. I record each one with the vulnerability it covers, an owner and an expiry date, and I test that it blocks the exploit itself rather than one example payload.

A combined engagement, common in South Asia and the Middle East, that pairs automated vulnerability scanning with manual penetration testing to find and then confirm weaknesses.

VAPT is often run annually or quarterly to satisfy audits, which makes it a point-in-time snapshot. I look at what happens next: whether findings get owners, deadlines and a retest, and whether anything is validated between cycles.

The ongoing process of finding vulnerabilities in systems and applications, prioritising them by risk, fixing or mitigating them, and verifying each fix.

I upgraded Tenable Security Center and deployed web application scanning for a Tier-1 Sri Lankan commercial bank. Scanning is rarely the weak point. Reconciling assets across tools, prioritising beyond CVSS and getting owners to fix things usually is.

A platform, usually delivered from a cloud edge, that combines a web application firewall with API protection, bot management and DDoS protection in front of web apps and APIs.

I have onboarded 230+ applications to WAAP across two programmes: about 112 to F5 Distributed Cloud for a leading Sri Lankan private bank, and about 120 to Imperva for a global apparel group. Inventory and cutover order decided more than policy did.

A security control that inspects HTTP traffic to a web application and blocks malicious requests, such as SQL injection or cross-site scripting, using rules and signatures.

A WAF in monitoring mode only reports. A common gap is a WAF still in monitor-only mode long after go-live, because nobody owned tuning. A safe path to blocking, application by application, is often my first recommendation.