Pre-submission checklist for the expertise: 20 items for web and mobile

Once you apply for the expertise, every finding costs time: a fix, a new build, a resubmission. It is better to do the main work in advance. The 20 items below come from taking our own product — a tax and finance SaaS platform and its Flutter mobile app — through the expertise, and from OWASP standards (Top 10, ASVS, MASVS, Mobile Top 10 2024). The list does not replace a full audit, but it helps close the most common issues ahead of time.

Web application and server (1–10)

1. HTTPS and HSTS

All pages open over HTTPS only, and http requests are redirected with a 301. The certificate chain is complete and outdated TLS versions are disabled.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

2. Security headers

Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options (or frame-ancestors in CSP), Referrer-Policy, Permissions-Policy. Remove headers that reveal server and framework versions.

3. Debug mode off

APP_DEBUG=false or your framework's equivalent. Error pages show no stack traces, SQL queries or file paths. phpinfo, Telescope and similar panels are closed.

4. Open ports

Scan the server from outside (nmap -Pn site.uz). Only 80 and 443 should be open to the internet. In our expertise, open FTP and control panel ports were a finding. The fix: a firewall, disabling unused services, and putting the panel behind an IP allowlist. SSH access by key and from restricted addresses only.

5. Proxy headers and Host

The app does not trust X-Forwarded-Host. Only X-Forwarded-For/Proto/Port, and only from your own proxy. The root URL is forced in production — otherwise password reset links can be built with a spoofed domain.

6. Information disclosure

The browser does not receive the full route list (for example via Ziggy), internal IDs, other users' data or excess fields. Review API responses: any field the frontend does not use should not be there. .env, .git, storage/logs and backup archives cannot be opened from a browser.

7. Authentication and rate limiting

Login, password reset and OTP routes are rate limited; messages do not reveal whether a user exists; OTPs are short-lived, single-use and attempt-limited.

8. Authorization

Ownership is checked for every resource: changing an ID does not open another user's document, payment or profile. Admin functions cannot be called with a regular user's token.

9. Business logic

Payment status changes only on the provider's server-side confirmation — the "success" page shows the real status from the database. Every state transition (submitting or approving an application, for example) checks the current state on the server. Both cases were findings in our web expertise.

10. Dependencies and file uploads

composer audit, npm audit or equivalent tools report no known vulnerabilities. Uploaded files are checked by type and size and are never executed as code.

Mobile app (11–18)

11. Root and jailbreak detection

The app detects rooted Android and jailbroken iOS devices and restricts operation. In our expertise this was a high finding on both platforms (MASWE-0097, OWASP Mobile M7).

12. Emulator, debugger and hook detection

Dynamic analysis tools such as Frida, attached debuggers and running in an emulator are detected. We closed this with a RASP library (freeRASP): when a threat is detected, the app shows a blocking screen.

13. Integrity check

The app detects re-signing or modification (tamper detection). The signing certificate hash is compared with the expected value.

14. Certificate validation and pinning

No badCertificateCallback or "trust all certificates" code. The certificate is pinned to specific root CAs: in Dart, a SecurityContext with trusted roots only; on Android, a pin-set in network_security_config.

15. Secure data storage

Tokens and personal data are not stored in plain SharedPreferences or UserDefaults but via flutter_secure_storage (Keystore/Keychain). WebView data and caches are wiped on logout.

16. Obfuscation

R8 minification is enabled on Android, and the Flutter build uses --obfuscate --split-debug-info. Endpoints and non-secret configuration are not stored as plain strings either. Server secrets are not in the app at all.

17. Backup and export

In AndroidManifest.xml:

<application
    android:allowBackup="false"
    android:dataExtractionRules="@xml/data_extraction_rules"
    android:usesCleartextTraffic="false" ...>

This keeps app data from moving to another device through a backup.

18. No unencrypted traffic

All requests and in-app links use https. Cleartext traffic is disabled on Android, and no ATS exceptions are added on iOS without justification. In our expertise, http links were recorded as a low finding.

Submission (19–20)

19. Checksums and the exact same build

The expertise asks for MD5, SHA1 and SHA256 checksums of the submitted APK/IPA:

sha256sum app-release.apk
md5sum app-release.apk
sha1sum app-release.apk

Take the checksums from the exact file you submit. After fixes: a new build and new checksums.

The build that was checked and the build that goes to the store must be the same. Otherwise the fixes exist in the documents but not in the app.

20. Documentation and test access

Prepare test accounts for the reviewers (with different roles), a system description, and a list of public URLs and APIs. When resubmitting, include a response document for each finding: what changed and how it was verified.

How to use the list

Mark each item "yes / no / not applicable" and keep evidence for every "yes": a screenshot, curl output, a config snippet. Queue the "no" items by severity. The same table will help later when you prepare your response to the expertise.

Summary

These 20 items are a short map of what the expertise looks at. Closing them in advance shortens the submit-and-resubmit cycle and gives the team a clear work plan.

Sipar runs this list, and broader checks, before the expertise: a Claude AI agent quickly reviews code, configuration and the build, and an expert confirms the findings and closes them. Request a security scan — we close the gaps before the audit.