Responsible testing

The tools in this track can check your own systems, and the same tools pointed at someone else's can harm them. The difference is permission. This lesson covers how to get it, how to stay inside it, and what to do when you find a real security problem.

Permission comes first

Load tests, scans, cloning and debugging are normal work on your own things. On anyone else's, the same actions can break a service, expose private data, or be a crime, whatever your intentions. Before you test anything you do not own, get permission from the person or organisation that does, and make it explicit.

A good permission covers the scope: exactly what you may do.

Scope question	Example answer
What may I test?	staging.shop.example and its API. Not the live site, not the payment provider
Which kinds of test?	Functional and load tests up to 50 virtual users. No denial-of-service attempts
When?	Weekdays 10:00 to 16:00, this week
With what data?	Test accounts only. Do not view or download real customers' data
Who do I tell if something breaks or I find a problem?	The team lead, by phone and email

Get it in writing, even if it is one email. If something goes wrong, you, and they, will know what was agreed. Anything outside the scope is outside your permission, even if it is "just one more check".

Load tests

A load test sends many requests on purpose to see how a server copes. That is exactly what an attack that knocks a service offline looks like. ApiWorkbench's load testing carries the same warning: run load tests only against servers you own or have permission to test, prefer a test or staging environment over production, and start small.

 a sensible ramp
 users  5 ──► 10 ──► 25 ──► 50      stop at the agreed limit,
         check  check  check  check   or as soon as errors climb

Remember that a third-party API your app calls (payments, maps, email) is someone else's service. Load-testing your app can load-test theirs too. Use a mock, such as one in Mock Studio, in its place.

Scanning

There are two kinds of scanning, with different rules:

• Scanning code, as in lesson 5, reads files. Scan code that you own or have permission to test. DL Sentinel attacks nothing, but its reports list weaknesses, so do not publish results about someone else's project.
• Scanning networks and running services (probing which ports are open on other machines, or testing a website for weaknesses) sends traffic to systems. Do it only on your own machines and networks, or with written permission and a scope. On your own computer, ss -tln from lesson 3 tells you what is listening without probing anything.

NFC and RFID cloning

NFC tags and contactless cards are everywhere: stickers, transit cards, office badges, hotel keys. An app such as NFC Wallet can read a tag and write a copy of its data onto a blank one.

Only copy cards and tags you own or have permission to copy. Copying someone else's access card, ticket or badge, or using a copy to get in somewhere, may be against the law and against the rules of whoever issued it.

It also helps to know what cannot be cloned, so you do not rely on a copy that will not work:

Tag	Can NFC Wallet copy it?
NFC stickers and tags with NDEF data (links, text, contact cards)	Yes, the NDEF data
Bank and payment cards	No. Protected by cryptography
Encrypted access cards and fobs (for example MIFARE DESFire)	No. Protected by design
The tag's serial number (UID)	No. Fixed in the chip on standard tags

A copy has a different serial number, so it works where only the content is read (a phone opening a link), not with a lock that checks the serial number or uses encryption. See Clone a tag.

Debugging other people's devices

Helping a friend or testing on a colleague's phone with DroidDeck or adb gives you a lot of access: their files, messages, photos and screen. Treat it as a privilege:

• Ask first, explain what you will do, and do it with the owner present.
• Touch only what the task needs. Do not open personal files or apps.
• When you finish, unplug, turn off wireless debugging, and ask them to remove your computer's authorisation (Developer options › Revoke USB debugging authorizations).
• Never debug a device you found, or one whose owner has not agreed. The Android track covers the details.

When you find a vulnerability

Sometimes you find a real security problem: an API that shows another user's order when you change a number in the URL, a key in a public repository, an admin page with no login. What you do next matters.

1. Stop. Do not explore further, do not download data, and do not test whether a found key works. Collect only what you need to describe the problem.

2. Do not share it publicly. No public issue, no social media post, no message in a group chat. Until it is fixed, details help attackers.

3. Find the right contact. In order of preference:

   • a SECURITY.md file in the project's repository, which says how to report;
   • the repository's Security tab on GitHub, where Report a vulnerability opens a private report if the project has turned it on;
   • a security.txt file at /.well-known/security.txt on the organisation's website;
   • the organisation's bug bounty or vulnerability disclosure page.

4. Write a clear, private report. What you found, where, the steps to reproduce it, what an attacker could do, and how you came across it.

5. Give them time to fix it. Agree on when it may be made public. Many programmes use 90 days as a default.

This is responsible disclosure (also called coordinated disclosure): the owner hears first and gets time to fix the problem before anyone else learns of it.

A report can be short:

Subject: Order details visible to other users in GET /api/orders/{id}

What:    Any signed-in user can read another user's order by changing
         the id in GET /api/orders/{id}.
Where:   https://shop.example/api/orders/1042 (found 2026-11-03)
Steps:   1. Sign in as a test user.  2. Open your own order (id 1041).
         3. Change the id to 1042. Another user's name and address appear.
Impact:  Names, addresses and order contents of all customers.
Note:    I viewed one record to confirm, did not save it, and stopped.

Your own SECURITY.md

If you publish a project, add a SECURITY.md file at the top of the repository so people know how to reach you privately:

# Security policy

## Reporting a vulnerability

Please do not open a public issue. Report it privately with GitHub's
"Report a vulnerability" button on the Security tab, or email
security@your-project.example.

We will reply within 7 days and keep you updated until it is fixed.

GitHub shows this file on the repository's Security tab.

Stay safe

• No permission, no test. Get the scope in writing, and stay inside it.
• Start small, use test environments and test data, and stop as soon as something looks wrong.
• Copy only tags and cards you own; debug only devices whose owners have agreed.
• When you find a vulnerability: stop, keep it private, report it to the owner, give them time.

Check yourself

QuizResponsible testing

Question 1 of 6

A client asks you to load-test their shop. What should you have before you start?

Score: 0

What you learned

• Permission and scope come before any test of something you do not own.
• Load tests, network scans, NFC cloning and debugging are all fine on your own things and can be harmful or illegal on other people's.
• Responsible disclosure means a private report to the owner, with time to fix, before anything is public.
• A SECURITY.md tells people how to report problems in your own projects.

Next steps

• Lab: Find the secrets
• Load testing guide
• Testing authentication