Security review & hardening
We test your app, API and cloud setup the way an attacker would, write up what we find in plain language, help your team fix it, then check that the fixes hold.
Start a projectWhat’s included
- Web application penetration testing
- The OWASP Top 10, plus the business-logic flaws scanners miss, like changing an order ID and getting someone else's order.
- Mobile application assessment
- Unpacking the shipped build, checking what it stores on the device, and testing the API calls it makes behind the UI.
- API security testing
- Authentication, token handling, rate limits, and object-level authorization on every endpoint in scope.
- Secure code review
- Reading the code paths that handle login, payments, file uploads and permissions, with tooling to cover the rest.
- Cloud configuration review
- IAM roles, storage buckets, secrets in environment variables, network exposure, and whether anything is logged at all.
- Hardening
- TLS and headers, least-privilege IAM, MFA on admin access, dependency pinning, backups that can't be deleted by the same credentials.
See it working
$ apktool d app-release.apk -o out
I: Decoding AndroidManifest.xml with resources...
$ grep -n 'exported="true"' out/AndroidManifest.xml
41: <activity android:name=".debug.AdminActivity" android:exported="true"/>
$ grep -nE 'allowBackup|usesCleartextTraffic' out/AndroidManifest.xml
12: android:allowBackup="true"
13: android:usesCleartextTraffic="true"
$ grep -rEn 'sk_live_|AKIA[0-9A-Z]{16}' out/
out/smali/com/example/pay/Config.smali:9: const-string v0, "sk_live_51H••••••••"
→ 4 findings · 1 critical (payment secret in the app) · 1 high · 2 medium
How it usually runs
- 1. Scope and rules
~1 week
What's in scope, test accounts, testing windows, and who to call if something breaks. Agreed in writing before any testing.
- 2. Test
1–3 weeks
Length depends on scope. Anything critical is reported to you the same day, not saved for the report.
- 3. Report and retest
Readout meeting, then a retest of the fixed findings once your team has shipped them.
What you have at the end
- A written report: a summary a non-engineer can read, then each finding with severity, steps to reproduce and a specific fix
- A readout meeting with your engineers to go through the findings
- A retest once fixes ship, and an updated report showing what was closed
One finding from a report, in the format we use:
Any signed-in user can read any invoice
- What we saw
GET /api/v1/invoices/10482returns the invoice. Changing the ID to10481returns another customer’s invoice, including billing address.- Fix
- Look the invoice up by
idand the session’saccount_id. Return 404, not 403, so IDs can’t be probed. - Retest
- Included once the fix is deployed.
Tools and platforms
- Burp Suite
- OWASP ZAP
- MobSF
- Frida
- Semgrep
- Nuclei
- Trivy
- Prowler
From our engineering notes
What went wrong, the code that fixed it, and what we do differently now.
- What we look at first when we unpack a mobile buildBefore any dynamic testing, the shipped binary tells you a lot. These are the first commands we run and what they tend to turn up.
- Your front-end bundle is public. Check what's in it.Secrets leak into JavaScript bundles through one misnamed environment variable or one wrong import. Checking takes a single command.
Questions we get
Will testing take our site down?
It shouldn't. We agree on testing windows, avoid destructive tests on production unless you ask for them, and can test against staging instead.
Can you sign our NDA first?
Yes. Send it with your first message and we'll return it before our first meeting.
Other services
Tell us what you're working on.
A few paragraphs is plenty. We'll read it, reply by email, and if it looks like a fit, set up a 30-minute Google Meet with an engineer.