Skip to content
Webb Technologies

Cloud & security · Testing

Security testing a custom web or mobile app before launch: automated checks, a pen test and evidence to keep

The app is nearly done, the launch date is on the calendar, and someone asks whether it has been security tested. A penetration test is booked for the week before launch, the report arrives with a dozen findings, and the team has to choose between moving the date and going live with known issues. Meanwhile the security questionnaire from a large customer asks for evidence nobody collected. This guide covers how to plan security testing for a custom web or mobile app from the start: what the app protects, which checks run automatically on every change, how to prove each role sees only what it should, when and how to bring in an independent penetration tester, and what evidence to keep.

Webb TechnologiesPublished 9 min read

Drafted with AI assistance; facts checked against any sources cited. General guidance, not advice for your situation; verify before relying on it.

On this page

In short

  • Write down what the app protects, who uses it and where it can be reached before choosing tests, so testing effort goes where the risk is.
  • Run automated checks in the deployment pipeline on every change: dependency and secret scanning, static analysis and infrastructure-as-code checks.
  • Test access control directly: for each role, prove in automated tests that it can reach its own records and nothing else.
  • Book an independent penetration test on a production-like environment early enough to fix and retest findings before launch.
  • Keep the evidence: scope, reports, fixes, retest results and a record of accepted risks, so the next security review starts from a file, not a scramble.

Where security testing goes wrong

  • Testing starts at the end. A penetration test the week before launch finds issues nobody has time to fix, and the launch slips or goes ahead with open findings.
  • Access control is assumed. The login works, so the app is called secure, but a user who changes an ID in a request can see another customer's or department's records.
  • Old dependencies. A library with a published vulnerability sits in the app because nothing checks for them after the first build.
  • Secrets in the wrong place. A database password or API key is committed to the repository or written into a configuration file on a server.
  • Cloud settings drift. A storage bucket, security group or role is opened for troubleshooting and never closed.
  • No evidence. The work was done, but when a customer's questionnaire asks for the last test report and how findings were handled, nobody can find it.

Questions people ask about an app's security, and what answers them

IT security

Example question
Has this app been tested, and are any high findings still open?
What answers it
The test report, the fix list and retest results

IT director

Example question
Can we launch on the planned date?
What answers it
Findings by severity with owners and target dates, and any risks formally accepted

Auditor or customer questionnaire

Example question
When was the app last tested, and by whom?
What answers it
Dated test reports, the tester's name and the scope

Developer

Example question
Does this change bring in a vulnerable library?
What answers it
Dependency scan results in the pipeline

Business owner

Example question
Can a user in one plant or customer account see another's data?
What answers it
Automated access tests for each role

Start with what the app protects

Before choosing tools, write one page on what the app holds and who could misuse it. A staff app on the internal network with no personal data needs different testing from a customer portal on the internet with order history and contact details.

Example threat notes for one app (your security team decides the content)

What data does it hold?

Example answer
Customer contacts, order history and uploaded drawings
What it changes in testing
Access tests per customer account, and checks on file upload and download

Who signs in, and how?

Example answer
Staff through single sign-on; customers with an email and password plus multi-factor
What it changes in testing
Tests of the sign-in flow, sessions and password reset

Where can it be reached?

Example answer
Customer pages on the internet; the admin area on the company network only
What it changes in testing
Confirm the admin area is unreachable from outside

What can a user change?

Example answer
Their own account details and uploads; staff can change order notes
What it changes in testing
Tests that users can't change other users' records or reach staff functions

What connects to it?

Example answer
A read-only reporting view in your database and an email sending service
What it changes in testing
Check the accounts the app uses have only the access they need

Published standards help turn this into a checklist. As of 2026, the OWASP Foundation's Application Security Verification Standard (ASVS) is at version 5.0, released in May 2025, with three levels of requirements to match an app's risk, and the OWASP Top 10:2025 lists ten categories of web application security risk, with broken access control first. For mobile apps, OWASP publishes the Mobile Application Security Verification Standard (MASVS). Pick the level and sections that fit the app, and agree them with your security team before building.

Automated checks on every change

Checks that run in the deployment pipeline catch the common problems long before a tester sees the app, and keep catching them after launch. A failed check stops the change from deploying until someone fixes it or records why it is acceptable.

Example pipeline checks (tools vary; the point is that each runs on every change)

Dependency scanning

What it catches
Libraries with published vulnerabilities, and outdated packages
When it runs
On every change, and on a schedule for newly published issues

Secret scanning

What it catches
Passwords, keys and tokens committed to the repository
When it runs
On every commit and pull request

Static analysis

What it catches
Common coding mistakes such as injection and unsafe input handling
When it runs
On every pull request

Infrastructure-as-code checks

What it catches
Public storage, open network rules, over-broad roles and missing encryption in the cloud definitions
When it runs
Before any infrastructure change deploys

Access control tests

What it catches
A role reaching records or functions it shouldn't
When it runs
With the app's other automated tests, on every change

Deployment credentials

What it catches
Long-lived cloud keys stored in the pipeline
When it runs
Set up once: the pipeline signs in to the cloud with short-lived OIDC credentials

Access control tests deserve particular attention, because they are specific to your app and no generic scanner can know your rules. For each role, write tests that sign in as that role and try to read and change records it owns, records another account owns and functions reserved for other roles. Our guide to single sign-on and least privilege for internal apps covers designing those roles.

An independent penetration test, planned early

  • Independent of the builders. A tester who didn't write the code looks at it the way an attacker would. Your security team, a testing firm or your customer may already have a preferred provider.
  • Book it with room to fix. Schedule the test when the app is feature-complete on a production-like environment, with time after it to fix findings and have the tester retest them. For example, two to four weeks before launch leaves room that the week before doesn't.
  • Write the scope down. The environments, addresses, roles and test accounts in scope, what is out of scope, testing hours, and who to call if something breaks.
  • Test a copy, not production data. Use a staging environment built from the same infrastructure code, with test data instead of real customer records.
  • Mobile apps. The app on the phone and the API behind it are both in scope. The API is where the data is, so it gets the same access tests as a web app.

Example handling of findings by severity (your security policy sets the actual rules)

Critical or high

Example
One customer can read another's orders by changing an ID
Example handling before launch
Fixed and retested before launch

Medium

Example
Session doesn't expire after a long idle period
Example handling before launch
Fixed before launch, or accepted in writing with a date

Low or informational

Example
A server header reveals a framework version
Example handling before launch
Scheduled into normal maintenance

Evidence to keep

  • The threat notes and chosen standard. The one-page summary of what the app protects, and the ASVS level or checklist agreed with security.
  • Pipeline results. Dependency, secret, static analysis and infrastructure checks, with dates, kept for the period your policy sets.
  • Test reports and retests. The penetration test report, the scope it covered, the tester's name and date, and the retest results for fixed findings.
  • Accepted risks. Any finding not fixed, with the reason, who accepted it and the review date.
  • Architecture and data flow. A current diagram of where the app runs, what it connects to and where data is stored, which security questionnaires ask for.

Keep this with the app's handover documents rather than in someone's inbox. Our guide to what a proper software handover should include covers the rest of that file.

After launch

  • Pipeline checks keep running. New vulnerabilities are published against libraries you already use; scheduled dependency scans catch them between releases.
  • Retest on significant change. A new role, a new kind of user or a new integration is a reason to test again, not only a calendar date. Many security policies also set a regular interval, for example yearly.
  • Patch on a schedule. Agree who applies updates to libraries, runtimes and the operating environment, and how quickly by severity. Our guide to what a proper software handover should include covers support options after handover.
  • Watch the logs. Sign-in failures, access denials and unusual volumes should reach someone through alerts, not wait for a monthly review.

Who does which part

Who typically covers each part of security testing (agree it in the contract)

Threat notes and chosen standard

Typically done by
The development team with your security team
What to check
That security signed off on the scope before building

Pipeline checks and access tests

Typically done by
The development team, as part of the build
What to check
That the checks are in the pipeline you'll own, not only on the developer's machine

Penetration test

Typically done by
An independent tester chosen by you or your security team
What to check
Scope, dates, retest included, and who receives the report

Fixes and retest

Typically done by
The development team, then the tester
What to check
Whether fixes to findings are within the fixed price or quoted separately

Ongoing scanning and patching

Typically done by
Your team or a support agreement
What to check
Who is alerted, and how quickly each severity is handled

Whichever way the work is split, write it into the proposal. Our guide to questions to ask before hiring a software development firm covers security review alongside ownership and handover.

Planning a custom app that has to pass security review?

Bring your security team's requirements, a note on what the app will hold and who will use it, and your launch date. On a scoping call we'll talk through the pipeline checks, access tests, test timing and what a fixed-price build would include.

Request a scoping call

Questions to settle before you build

Take this to IT security, the business owner, the development team and procurement

  • What data will the app hold, who signs in, and where can it be reached?
  • Which standard or checklist, and which level, has security agreed for this app?
  • Which automated checks run in the pipeline, and what stops a deployment?
  • Which roles exist, and are there automated tests that each one sees only its own data?
  • Who performs the penetration test, on which environment, and when?
  • How are findings handled by severity, and who can accept a risk?
  • Where are test reports, fixes and accepted risks kept, and for how long?
  • Who scans, patches and retests after launch?

If the app isn't written down yet, our project brief builder asks eight short questions and turns the answers into a one-page brief you can share with security and IT before a call.

Our experience includes full-stack web applications, native iOS and cross-platform mobile apps, OAuth and OIDC authentication flows, security hardening and compliance practices, and CI/CD pipelines with GitHub Actions and OIDC on AWS. See custom software development for how we'd approach a build like this, and how we work for the fixed-price process.

Sources

See it applied

Share this guide

Email to a colleague

Related services

Topics

More guides

Keep reading

All insights →

Security · Identity

Securing internal apps with single sign-on, Entra ID and least privilege

8 min read

AI integration · Data access

Connecting AI to your internal data safely

10 min read

Want to talk through your version of this?

A 30-minute call. You leave with a clear approach and the real risks, whether or not you hire us.

Request a scoping callinfo@webb-technologies.com