Pre-launch security checklist: test sign-in and payments

Most security problems in a young web app are not exotic. They sit in the two places every product has to get right on day one: sign-in, where a mistake hands someone else's account to a stranger, and payments, where a mistake gives away the product or charges the wrong amount. This pre-launch security checklist covers both, drawn from the OWASP Cheat Sheet Series, with a concrete way to test each item before launch and one worked test of a checkout.

How to use this pre-launch security checklist

Run it against a test copy of your app that matches production: same sign-in provider, same payment gateway in its test mode, same webhooks. Use test accounts and test data, never real customers. Open your browser's developer tools, because several checks involve changing a request and sending it again. For every item, write down what you did and what happened. When you fix something, run that check again; a fix that was never retested is a guess.

Sign-in: accounts and passwords

Error messages do not reveal which accounts exist. Try signing in with a real email and a wrong password, then with an email that has no account. OWASP's guidance is that login, password reset and recovery all answer with the same generic message either way. If one says "wrong password" and the other "no such user", anyone can test a list of emails against your site.
Password rules follow current guidance. OWASP, citing NIST, treats passwords shorter than 15 characters as weak when there is no multi-factor sign-in, and shorter than 8 when there is. Allow at least 64 characters so people can use passphrases. Block common and previously breached passwords, and do not force periodic changes.
Guessing is slowed down. Send many wrong passwords for one account, quickly. Something should push back: a delay, a lockout or a CAPTCHA.
Sensitive changes ask again. Signed in, try changing the email or password. OWASP recommends asking for the current password first, so someone who finds a signed-in laptop cannot take the account over.
Everything is on HTTPS. The sign-in page and every page after it should only be reachable over TLS.

Sign-in: password reset and sessions

Password reset is a second front door, and it is often weaker than the first.

The reset form gives nothing away. Request a reset for a real and a fake address. The message should be the same, and so should the time it takes to answer: OWASP notes that a fast reply for unknown accounts tells an attacker which ones exist.
Reset links are random, single use and short-lived. Use a reset link twice; the second time should fail. Wait past the expiry and try again. Request two links and check the first stops working.
Reset requests are limited. Send many reset requests for one account. Without a per-account limit, someone can flood a person's inbox.
Old sessions can be ended. After a reset, the user should be offered the chance to sign out everywhere else, or it should happen automatically. Sign in on two browsers, reset the password in one, and see what happens to the other.
Signing out really signs out. Copy the session cookie, sign out, then send a request with the old cookie. It should be refused. OWASP's session management guidance is clear that the server must end the session; deleting the cookie in the browser does nothing to a copy someone else holds.

The OWASP forgot password cheat sheet covers the reset checks in more depth.

Payments: never trust the browser

The rule behind almost every payment check is the same: anything the browser sends can be changed. OWASP's payment gateway integration cheat sheet lists price tampering through the client as a core risk.

The server sets the price. Start a checkout, then change the price, quantity, discount code or product ID in the request before sending it. Your server should rebuild the cart from its own data and recalculate the total, ignoring what the browser claimed.
The success page does not unlock anything. Visit your "payment successful" or return URL directly, without paying. Nothing should be granted. The order should only be fulfilled after your server asks the gateway's API whether the payment really went through.
The amounts match. When the gateway confirms a payment, check the amount, the currency and the order ID all match what you expected, not just that "a payment" succeeded.
Webhooks are verified. Send your webhook endpoint a fake "payment succeeded" event without the gateway's signature. It should be rejected. Only server-to-server notifications that pass the signature check should count.
The same event twice does nothing twice. Replay a real, signed webhook. The order should be processed once, not shipped twice or credited twice. This is called idempotency, and it matters because gateways do retry deliveries.
Logs help without leaking. Check that payment attempts and callbacks are logged with enough to trace an order, and that no card data, secrets or full request bodies end up in the logs.

A worked example: one afternoon on a test checkout

Say you sell a yearly plan and a monthly plan, and checkout sends people to your payment gateway. With the gateway in test mode on your staging copy, one afternoon covers the payment half of this list:

Tamper with the cart. Start buying the yearly plan, find the checkout request in developer tools, change the plan ID to the monthly plan while the page still says yearly, and send it. The gateway should show the price your server worked out for the plan it actually received, and your records should match.
Skip the payment. Copy the return address the gateway sends people back to after paying. Open it in a fresh test account that never paid. The account should stay on the free side.
Forge a webhook. From your own machine, send your staging webhook endpoint a made-up "payment succeeded" event with no signature. Check that it is refused and that nothing changed in the database.
Send one twice. Make a real test payment, capture its signed webhook, and send it again. The account should be upgraded once, with one order in your records.
Read the logs. Find the entries for all four tests. You should be able to follow each order, and you should find no card numbers or secrets.

If any step fails, you have found a launch blocker cheaply, in test mode, before a real customer or attacker did.

What a checklist will not catch

A list finds the known mistakes. It will not find a flaw in the way your own product works: a team member who can see another team's invoices, a trial that can be restarted forever, a refund that leaves access switched on. The first of those is broken access control, which has its own testing guide. The others come from someone reading your app with an attacker's eye, which is why it is worth having a person who did not build it test it before launch, and again after big changes.

That is work whitehatstoic does. Its security testing covers web app and API review, ends with a written report and fixes, and includes a retest once the fixes are in. Auditing sign-in and payments is named on its home page, and for new products it also builds accounts, payments and admin as part of full-stack development. Testing is scoped after a short call, and no test can promise to find every weakness.

Frequently asked questions

Can we run these checks on the live site?

Run them on a staging copy with the gateway in test mode. If something must be confirmed on the live site, use only your own accounts and agree it with whoever runs the system first.

How long should passwords be?

OWASP, citing NIST, treats passwords under 15 characters as weak without multi-factor sign-in and under 8 with it, and says to allow at least 64 characters.

Is the payment success page enough to confirm a payment?

No. Your server should confirm the payment with the gateway's API and check the amount, currency and order ID before it unlocks anything.

When should we repeat the checklist?

Before each launch, and after any change to sign-in, password reset, checkout or webhook code.

Get started

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.