Your basket

Sloppy deploys leave the app config in the web root. It is one file, its name starts with a dot, and every framework uses the same one.

Think about what a developer drops in the web root while setting a site up and forgets to delete. A plain text file with a name like install, setup or notes.

The file that tells search engines what to skip is a list of the paths the owner did not want found.

Same idea as the notes file. Backups get written into the web root and left there — try the obvious archive names.

Before guessing anything clever, try what the software shipped with. The most tired username and the most tired password.

The site decides who works here by looking at the address you sign up with. Nothing checks that you can actually receive mail there. The company domain is in the leaked config.

The signup form sends three fields. The account record holds more than three. Add one the form never sends and see whether the server keeps it.

Enter the password and stop at the code screen. Do not solve it — go somewhere else on the site by typing the address in yourself, and see whether you are treated as signed in.

One of your cookies is three blocks of text with dots between them. The first two are only encoded, not protected — decode them and you will see who the site thinks you are, and what it claims is guarding the token. Change both blocks and hand it back.

A signature is only worth something while the key behind it is secret. This deploy wrote its key down, in one of the files it left sitting in the web root.

You can read your own mail in the mailbox, but not anybody else's — so the code has to be made to arrive somewhere you can see. The forgotten-password form sends more than the box you can type in: one of its fields decides which site the link in that email points at, and nothing checks that site is this shop. You cannot run a server from in here, so the lab captures anything the shop addresses elsewhere — the collector is linked at the bottom of this panel.

Ask for a code on your own address first and read it in your mailbox, so the code is honestly yours. Then look at the form you type it into: the code is not the only thing it asks for, and nothing checks that the two belong together.

Count the digits in a code you have been sent, and work out how many codes that is altogether. Then ask what stops you from sending all of them: a lockout, a delay, a puzzle, a cap on tries? Point a tool at the form, give it every code in that range, and watch for the answer that is not the same size as the rest. Pace it at about 50 a second — the web server in front of the lab drops anything faster, and a dropped request could be the one that worked. That limit is out in the proxy, not in the shop.

Open one of your own invoices and look at the number in the address bar. Then change it.

Your own profile page has your account number in the address. The accounts either side of it belong to somebody.

Look at every field the checkout form sends, including the ones you cannot see on the page. Ask which of them the server should have looked up for itself.

The server checks whether you have used it, then takes a moment, then applies it. Send several requests at the same instant so they all pass the check before any of them finishes.

Type a single quote into the search and read the error it gives back. It tells you the shape of the query. Once you can end the quote yourself, you can add a second query to the first — the trick is that both halves must return the same number of columns, and the error keeps telling you when they do not.

The panel builds its login the same careless way the search does. If the password can never be checked, what is left of the check? Ending the username early and commenting out the rest of the line is the classic shape.

Reviews come back onto the product page exactly as they were typed. Ask whether they come back as text, or as part of the page.

The shop repeats your search term back to you above the results. Watch how it is written into the page.