Before handover. Before launch. After changes.
Your app works. Are data permissions right?
Check your application’s security before accepting a developer’s handover. Clear findings for you, technical remediation for your developer, and a retest after fixes.
For owners of SaaS products, CRMs, online stores and customer portals.
Early access: a request does not start a scan or require payment.
01 / Questions before handover
A working screen does not prove access is protected
Can a staff member perform an admin action?
Are downloads and exports protected too?
Are internal pages and files exposed?
02 / Checks and prerequisites
What you can check
External configuration
HTTPS/TLS, exposed service endpoints and publishing mistakes within the supported profile.
Requires: A verified target and permission to scan.
User separation
User A’s access to user B’s test objects.
Requires: Two test accounts and objects with known owners.
Roles and organizations
Cross-organization access and role-restricted operations.
Requires: Test roles, organizations and expected permissions.
Documents and exports
Access checks for prepared files, downloads and exports.
Requires: Test documents, links and expected permissions.
Verify the fix
Repeat the selected scenario after a developer’s changes.
Requires: An available environment, matching conditions and retest allowance.
A URL alone cannot test private workflows. Partial coverage means some checks did not run: for example, missing accounts, an unavailable environment or an exhausted budget. The report must retain the reason.
03 / Workflow
From your app URL to a verified fix
Create a project
Add your app URL, verify control through DNS or a verification file, and authorize scanning.
Prepare with your developer
Agree on roles and test objects. Active state-changing scenarios require staging and separate consent.
Review findings and coverage
Read the risk explanation, evidence, and checks that could not run with their reasons.
Share tasks and retest
Share technical remediation with your developer. After a fix, repeat the scenario and compare results.
Preparation instructions for your developer
Send this checklist to your developer
You do not need to receive passwords. An authorized project member performs the configuration.
Prepare staging and confirm scanning authorization. Create separate test accounts A and B, roles and two test organizations. Prepare synthetic documents for each user and a matrix of who may read, modify and export each object. Configure supported routes and authentication in the project’s protected settings. Do not send passwords, tokens or real customer data to the owner. Separately authorize active state-changing scenarios. Preserve matching conditions for retesting after fixes.Team access depends on the plan: Pro has one member; Business follows the catalog allowance. AI setup instructions can help with preparation but do not replace ownership verification or consent.
AI assistant setup instructions →04 / Sample report
Readable for the owner. Actionable for the developer.
Demonstration mock-up, not an actual scan result. All users, documents and evidence are synthetic.
DEMO-001 · staging · release demo-v1 · 2026-11-04 12:00 UTC
Owner view
Found: access to another user’s document.
User A could download user B’s test document. If this workflow also exposes real data, private documents could reach the wrong people.
Action: deny unauthorized access, then verify rejection for A and continued legitimate access for B.
Developer view
GET /api/documents/demo-b/download
Identity: test-user-a
Expected: 403 or 404
Observed: 200 + synthetic document markerCheck ownership and organization server-side before reading the file. Do not trust the request’s documentId. Repeat the negative A → B test and the positive B → B test.
Statuses should expose limitations
Found
An observed violation in an executed scenario.
Not found in the executed scenario
Does not establish application-wide security.
Not executed
For example: a second account was not provided.
Needs clarification
Expected access permissions are not defined.
Fix verified
Retest confirmed rejection and legitimate access.
Persists
Retesting reproduced the issue.
Example scope: one synthetic document download using two users. Other routes, roles, organizations and production are not covered.
Useful beyond the first launch
Before launch
Check prepared scenarios before real customers arrive.
When accepting changes
Repeat important checks after changes to roles, APIs and documents.
During maintenance
Use repeat scans, retests and dependency monitoring within your plan.
05 / Plans
Choose your checking capacity and team access
The current Scantelio catalog. Business increases capacity and team features; it does not guarantee detection of more vulnerabilities.
The catalog is temporarily unavailable. We do not display unverified prices. Refresh this page or contact support.
Monthly allowances reset each UTC calendar month; annual billing does not increase them. Taxes and the final total appear at checkout. A zero allowance means the feature is not included. Payment availability depends on billing configuration.
Before you start
Can I use this without a technical background?
Yes: start with the URL and readable report. Ask your developer to prepare test accounts and expected permissions for private-data checks.
Is a URL enough?
Only for part of the external profile after verification. Access checks require test users, roles and objects.
Does this rate my contractor?
No. We check application security properties in specific scenarios, not a contractor’s work quality or professionalism.
Can I scan someone else’s website?
Only with authority and the owner’s permission. Target control must be verified.
Can a scan change data?
Active scenarios may perform test changes. They require staging, explicit consent and test data. Do not use real customer data.
What does my developer receive?
Reproduction steps, redacted evidence, expected permissions, remediation guidance and retest conditions.
Are retests unlimited?
No. Availability and quantity depend on your plan; current limits are shown below.
No findings: can I accept the project?
This is not a verdict of complete security. Review what ran, what was skipped and which business requirements still need validation.
Do you provide a certificate?
No. Scantelio does not issue security certificates or replace a full penetration test.
Next step
Make decisions with clear evidence
Start by preparing your project. After the report: developer tasks, fixes and a retest, rather than a promise that everything is secure.
Having trouble? Contact us for help getting connected. Support →