Security testing: a practical guide for web and mobile apps

Most breaches are not clever. Someone forgot to check who was allowed to open a URL, an old library had a known hole nobody patched, or a config file shipped to production with debug mode still on. That is the boring truth about security testing: the majority of real damage comes from mistakes any decent review would have caught, not from a hacker in a hoodie cracking encryption at 3am.

This guide is written from the building side. At Zarle we ship production apps for hospitals, fintech-adjacent products, and consumer platforms, so this is not an academic topic for us. It is the difference between a patient portal that keeps records private and a headline nobody wants. Here is what it actually is, the main types (SAST, DAST, penetration testing, vulnerability scanning), how the OWASP Top 10 fits in, the tools worth knowing, when in the project to run each check, and why this matters more for some industries than others.

What security testing actually is

Security testing is the practice of deliberately trying to break your own application before someone else does. You probe the app the way an attacker would, look for weak spots in the code, the running system, the dependencies, and the configuration, then fix what you find. It sits alongside functional testing but asks a different question. Functional testing asks "does the feature work?" The security question asks "can this feature be abused?"

Those are not the same thing. A login form can work perfectly, log real users in, validate passwords, and still let an attacker enumerate every account or bypass the check with a crafted request. The feature passes. The security check fails. That gap is exactly where this work earns its keep.

The other thing worth saying early: it is not one activity. It is a set of overlapping methods, each catching a class of problem the others miss. Run only one and you will have blind spots. The good teams layer several.

The main types of security testing

There are four methods you will hear about constantly. They are complementary, not competing.

SAST (static application security testing)

SAST reads your source code without running it. Think of it as a very pedantic reviewer that scans every line looking for dangerous patterns: SQL built by string concatenation, hardcoded secrets, unsafe deserialization, missing input validation. Because it works on the raw code, it is sometimes called white box testing, testing from the inside with full visibility.

The strength of SAST is that it runs early and fast. You can wire it into a pull request so a developer gets flagged before the code ever merges. The weakness is noise. Static tools throw a lot of false positives, and they cannot see problems that only appear when the app is running.

DAST (dynamic application security testing)

DAST attacks the app while it is running, from the outside, with no view of the source. It crawls the pages, pokes at every input, sends malformed requests, and watches how the app responds. This is black box testing, and it behaves a lot like an automated attacker knocking on every door.

DAST catches things SAST cannot: authentication flaws, server misconfiguration, broken session handling, runtime injection. The trade-off is that it needs a deployed, working environment to test against, and it runs later in the cycle. It also cannot tell you which line of code is at fault, only that a given endpoint is vulnerable.

Penetration testing

Penetration testing is a human doing what automated scanners cannot: thinking. A skilled tester chains small weaknesses into a real attack, escalates privileges, and reasons about business logic. A scanner will never notice that a coupon endpoint lets you set your own discount to 100 percent, because technically nothing is malformed. A person will.

Pen testing is the most expensive method and the slowest, so you do it at milestones, before a big launch, after a major architecture change, or on a schedule for regulated products. It is also the method auditors and enterprise clients ask for by name.

Vulnerability scanning

Vulnerability scanning checks your servers, containers, and dependencies against giant databases of known flaws. It answers a narrow but vital question: are you running any software with a publicly known hole? Given that outdated components and supply chain issues sit near the top of every risk list, this is cheap insurance you should automate and forget.

Here is how the four compare at a glance:

You will also see two more acronyms. IAST (interactive) instruments a running app to combine inside and outside views, and SCA (software composition analysis) focuses purely on third-party and open-source dependencies. Both are useful, but the four above are the foundation.

The OWASP Top 10, and why it anchors everything

If you do nothing else, test against the OWASP Top 10. It is a consensus list of the most critical web application security risks, rebuilt from data across millions of real applications, and it tells you where the actual damage happens rather than where it theoretically could. The 2025 edition analysed over 2.8 million applications and mapped 248 underlying weaknesses across ten categories.

The current list looks like this:

• A01 Broken access control (still number one, users doing things they should not be allowed to)
• A02 Security misconfiguration (jumped up the list, think default settings, debug mode, open buckets)
• A03 Software supply chain failures (new and broader, your dependencies and build pipeline)
• A04 Cryptographic failures (weak or missing encryption of sensitive data)
• A05 Injection (SQL, command, and cross-site scripting still very much alive)
• A06 Insecure design (flaws baked in before a line of code is written)
• A07 Authentication failures (weak login, session, and identity handling)
• A08 Software or data integrity failures (unverified updates and CI/CD tampering)
• A09 Security logging and alerting failures (you got breached and never knew)
• A10 Mishandling of exceptional conditions (new, apps failing in unsafe ways)

Two things stand out in the 2025 update. Supply chain risk got its own expanded category, which reflects how much modern apps lean on open-source packages you did not write. And there is a new emphasis on failing safely and actually alerting when something goes wrong, prevention alone is no longer treated as enough. When we plan security testing for a client, this list is the checklist we start from, because it keeps effort pointed at real risk instead of exotic edge cases.

A security testing process that works

You do not need a huge team to do this well. You need it to happen at the right moments instead of once, in a panic, the week before launch. Here is the rhythm we use on projects.

Shift left: test while you build

The cheapest bug to fix is the one caught in a pull request. Wire SAST and dependency scanning into your pipeline so every commit gets checked automatically. A developer sees the warning in minutes, fixes it in context, and it never reaches production. This is what people mean by shifting security left, moving the checks earlier where they cost almost nothing.

Threat model before you code the risky parts

For anything sensitive, payments, health records, admin panels, spend an hour asking "who would want to break this, and how?" before building it. Insecure design sits on the OWASP list precisely because you cannot test your way out of a flaw that was baked into the architecture. Threat modelling is not paperwork, it is ten minutes of thinking that saves a rebuild.

Scan the running app regularly

Once there is a staging environment, point DAST at it on a schedule. Automated dynamic scans catch the runtime problems static analysis misses, and running them often means you find regressions fast instead of discovering them all at once.

Bring in humans at milestones

Before a major launch, after a big change, or on a compliance cadence, get a real penetration test. This is where the subtle, high-value stuff surfaces: broken access control, logic abuse, and the chained attacks scanners cannot imagine.

Fix, retest, and log

Finding issues is half the job. Prioritise by real impact, not by the scanner's scary red label, fix them, and retest to confirm the fix holds. And make sure the app logs and alerts on suspicious behaviour, because A09 exists for a reason: plenty of companies got breached and only found out months later.

A simple checklist to keep yourself honest:

• SAST and dependency scanning run on every pull request
• Secrets are never committed, and scanning enforces it
• DAST runs against staging on a regular schedule
• A penetration test happens before major launches
• Access control is tested for every role, not just the happy path
• Logging and alerting are in place and actually monitored
• Findings are tracked to closure, then retested

Tools worth knowing in 2026

You do not need all of these. Pick one per layer and use it consistently.

• OWASP ZAP, the leading open-source DAST scanner, free and easy to run in CI/CD.
• Burp Suite, the tool most professional pen testers reach for, excellent at finding the chained, logic-based flaws automated scanners miss.
• SonarQube, static analysis and security hotspot detection that plugs into your pipeline and IDE.
• Snyk, developer-first scanning across code, dependencies, containers, and infrastructure.
• Nmap, Nessus, and Metasploit, the classic trio for network scanning and validating exploits during a pen test.

The tool matters less than the habit. A free scanner run on every build beats an expensive platform nobody looks at.

Why security testing matters more in some industries

Every app needs some of this. Some cannot ship without it.

In healthcare, you are handling records that carry legal weight and personal harm if leaked. When we built the patient portal for Dr Prakash Hospital, moving 70 percent of appointments online and adding telemedicine, security was not a feature we bolted on at the end. Access control, encryption of patient data, and careful session handling were part of the design, because a healthcare portal that leaks records is worse than no portal at all. HIPAA-grade thinking, strict control over who can see what, shaped the build from day one.

Fintech and payments are the same story with money attached. A logic flaw in a checkout or wallet flow is not an inconvenience, it is direct loss. This is exactly the category where automated scanners fall short and human penetration testing pays for itself, because the dangerous bugs are the ones that look like normal features.

For consumer apps, the stakes feel lower until you have real users. An app with 10,000 downloads in a month is an app with 10,000 people's data to protect. Scale turns a minor flaw into a real incident, so building the testing habit early, while the app is small, is far easier than retrofitting it after you are popular.

Mobile adds its own surface: insecure local storage, hardcoded API keys in the app bundle, weak certificate handling, and backend endpoints that trust the client too much. Testing a mobile app means testing the app and the API behind it, because attackers do not politely use your official client.

Frequently asked questions

How much does security testing cost in India?

It varies widely by scope. Automated scanning wired into your pipeline is essentially free beyond setup time. A professional penetration test for a web app in India typically runs from roughly 50,000 to 3,00,000 INR depending on the size of the application, the number of user roles, and whether compliance sign-off is required. The right way to think about it is not cost but comparison: a single breach of patient or payment data costs far more than any test.

How often should we run these tests?

Automated checks (SAST, dependency scanning, DAST) should run continuously, on every commit or on a nightly schedule. Human penetration testing is milestone-based: before a major launch, after significant architecture changes, and at least annually for anything handling sensitive data or subject to compliance.

What is the difference between DAST and penetration testing?

DAST is automated. It crawls a running app and probes it with known attack patterns at scale, fast and repeatable. Penetration testing is a human doing the same job with judgement, chaining weaknesses and reasoning about business logic in ways a scanner cannot. DAST gives you breadth cheaply, pen testing gives you depth. You want both.

Can it be fully automated?

Partly. Automation handles the repetitive, high-volume checks brilliantly: known vulnerabilities, insecure code patterns, misconfiguration. What it cannot do is reason about intent. Logic flaws, privilege escalation, and abuse of legitimate features still need a human. The best programmes automate the mechanical layer and reserve people for the thinking.

Does a small startup really need security testing?

Yes, but proportionate to your stage. You do not need an enterprise pen test on day one. You do need dependency scanning, no committed secrets, sane access control, and encryption of anything sensitive. These cost almost nothing and prevent the failures that most often sink small products. Build the habit while the codebase is small.

What is the single most common security flaw you see?

Broken access control, by a wide margin, which is also why it sits at the top of the OWASP list. It is the classic case of a user reaching data or actions they should not, an admin URL that is not actually protected, or an API that returns another user's record by changing an ID. It is common because it is invisible to functional testing, the feature works, it just works for the wrong person.

How does it fit into a normal development timeline?

It should not be a separate phase at the end. Static and dependency scanning live in the pipeline from the first commit, threat modelling happens before you build the risky parts, dynamic scanning runs against staging, and a penetration test slots in before launch. Woven through the project like this, it adds very little time. Bolted on at the end, it becomes an expensive scramble.

Build it secure from the start

Security testing is not a box you tick before launch. It is a habit that runs through the whole build, from the first pull request to the production monitoring. Layer the methods, anchor your effort in the OWASP Top 10, automate the mechanical checks, and bring in humans where judgement matters.

If you are building a web or mobile product where security is not optional, healthcare, fintech, anything holding real user data, our team designs authentication, access control, and encryption into the backend from day one rather than patching it later. Have a look at our backend and cloud services and tell us what you are building.