AppScan Studio actively tests your deployed OutSystems app from the outside — proving which endpoints leak data, skip authorization, or answer to the wrong role, instead of guessing from the source.
Paste a URL — or upload an APK for closed-network apps. AppScan reads the published app the way an attacker would; optional OSP upload adds source-level analysis when you want it.
Point AppScan at your published OutSystems app. We pull the public surface — every screen, every server action, every response header — exactly the way an attacker would see it.
Every screen, action, and endpoint is checked for known risk patterns: pages reachable without login, customers able to see each other's data, server actions named in ways that often hide privilege gaps. Ranked by severity, not by where they came from.
Mark findings as fixed, ignored, or false positive. Compare against the previous release to see what's new. Share scoped, expiring links with stakeholders.
A scan tells you what your app exposes. The probe calls those endpoints for real and tells you whether they're actually protected — anonymously, and, when you supply a test login, as a logged-in user. Every verdict comes with the request and response that produced it.
The part generic scanners miss. We swap object ids between identities to catch IDOR / BOLA, flip privilege booleans and role values, and tamper with the client-side variables your app trusts — then compare what comes back against the legitimate baseline. Confirmation of a write endpoint is opt-in and uses two test identities with a read-back check.
Each input gets variants matched to its declared OutSystems type — Integer, Date, Text, Boolean — plus boundary stress and the canonical SQLi / CMDi / path-traversal classics. SQL injection uses a differential oracle rather than error strings alone. Aggregates are skipped on purpose: the platform parameterises them, so they aren't injectable.
Responses are graded Critical / High / Medium / Low / Info by signature, not raw HTTP status. Credentials and keys returned in a payload, excessive data exposure on paginated endpoints, SQL error leakage — each finding carries its CWE + OWASP reference and a reproduction curl command.
Re-probing an app only re-fires the endpoints whose version actually changed, carrying unchanged verdicts forward — so a routine re-check after a release is a fraction of the first run. Force a full sweep whenever you want one. Per-app rate limits keep fragile environments safe.
One-click export as SARIF v2.1.0 (drops straight into GitHub Advanced Security or any IDE that speaks the standard) or as a polished PDF — cover, executive summary with severity donut, per-finding detail blocks, glossary.
Every finding category maps to its PCI DSS 4.0 / ISO 27001 / SOC 2 control reference in the PDF report. Hand it to auditors without translating from CWE numbers yourself.
The dashboard view of every scan, every status, every release — designed to be skimmed in seconds before a deploy.
Every scan in one table — live status, findings, and what's new since the last release. Filter by URL, sort by danger or suspicion, drill into a report.
The same run, seen four ways — the app's health overview, the active endpoint probe that proves what's exposed, the findings summary banded by how much to trust it, and the full module-by-module report.
After a probe, one overview page per app: how much of it was tested, a plain ship / don't-ship verdict, the way risk is trending across scans, and the exact findings to fix first.
The probe fires real requests at every endpoint — payload sweeps and authorization checks — and grades each response from Critical to clean. "Looks exposed" becomes "proven exposed," with the request and response kept as evidence.
One page gathers every finding across all modules and sorts it by how much to trust it — fix now, validate, inspect, reference — so you start with what's confirmed and exploitable instead of a flat list.
The complete scan: what it walked — modules, files, size — plus the feature toggles, site properties and client variables that quietly change what the app does, flagged wherever a browser-editable value is standing in for a real security control.
Findings carry a disposition that follows the endpoint across re-scans — mark one fixed and it stays quiet, unless it comes back, in which case it's flipped straight back to you for review.
Sometimes. But a human reviewer runs out of working memory as your factory grows past one person, and source-time tools like AI Mentor read what you wrote — not what your deployed app actually exposes once a release is published. AppScan tests the running app from the outside. All three are useful; they don't see the same things.
Source-time tools — AI Mentor included — read what you wrote. AppScan reads what your customers get: the live URL, the published role, the response your app returns today. The same code can ship differently across environments; only the runtime sees that.
A reviewer skims the same BackupOldOrders action on every PR for two years. AppScan triages it once and silences it on every future scan — only what's new gets your attention.
A reviewer sees the PR they're assigned. AppScan walks every screen, every server action, every module — including the ones nobody actively owns and the ones a junior dev shipped six months ago.
Code review and source tools flag issues per file. AppScan diffs scan vs. scan — what's new since last release, what's still triaged from last quarter, what was silently fixed. Releases, not files.
Alice catches role misuse. Bob misses it because he's tired. AppScan applies the same curated pattern set on every scan — no off days, no gaps between reviewers.
A scan written outside your IDE is an independent check on the assumptions inside it. If something says it's "Registered" but the deployed endpoint answers anonymously, AppScan catches the gap. Defense in depth, layered on purpose.
Designed around the way OutSystems teams actually work — release cycles, modules, and PMs who need a plain-English summary.
Flags screens left open to Anonymous or stuck on generic Registered — the access-control gaps that turn into data leaks.
Spots endpoints that take internal IDs without ownership checks — the pattern attackers use to enumerate other users' records.
Compare two scans. Get a dev-facing changelog and a PM-friendly summary — engineers and stakeholders read the same release notes.
Put an app on a schedule — anywhere from every 15 minutes to weekly — and AppScan re-probes it on its own. Newly-critical findings raise an in-app badge and go out by email or to a webhook (Slack, Teams, or your CI), once per report, so nobody has to remember to check.
One page per release that bundles the findings that matter for a go/no-go call with a recorded review verdict — approved, approved with conditions, or blocked — and exports as a PDF you can attach to the change record.
Upload an .apk or .aab and AppScan analyses the bundle itself. Where an app has both a package and a live URL scan, a merged view combines the two perspectives and a delta view shows what exists in one but not the other.
The questions every procurement and security team asks before signing — answered in-product, not in a slide deck.
TOTP (Google Authenticator, Authy, 1Password) enforced for every user, with backup codes and remember-device. No password-only logins anywhere.
Every login, scan start, role change, API key use, and admin action lands in an append-only audit log, with the actor, source IP, country, timestamp and outcome. Account Admins see their tenant's slice; full history is exportable.
Programmatic access via Authorization: Bearer aps_…. Per-token read / write scopes, revocable with immediate effect, every use written to the audit log, and per-key rate limits. Keys are issued on request — ask and we'll provision one for your tenant — and the full endpoint reference is browsable in-product with an OpenAPI document for your tooling. Drop into your CI/CD pipeline.
Standard SARIF output for runtime findings. Drops straight into GitHub Advanced Security, GitLab SAST integration, or any IDE / dashboard that consumes the format.
One-click async export of every record we hold for your tenant — reports, users, audit log, API keys metadata. ZIP delivered by email + page download, valid for 7 days.
Upload your own logo and we replace ours on the cover of every PDF report. Same scanner, your branding for executive readouts and customer-facing audits.
Your organisation's data is walled off from every other tenant — reports, users, settings and API keys are only ever reachable by your own account, never another customer's. Identifiers are opaque and random, so nothing can be guessed or enumerated from someone else's.
Infrastructure in the EU, processed by QUICKSYNC, UNIPESSOAL LDA (Portugal). Data residency answer comes pre-checked on the procurement form.
These rules don't prove a vulnerability — they spot server actions whose names land in territory that's worth a closer look. Same rules drive every count, pill, and diff in the app.
Names that consistently land in high-impact territory — the kind of code reviewers always want to look at twice before a release ships. The exact pattern set is curated and updated as we learn what teams actually miss.
Naming and shape patterns that point to code which probably shouldn't have shipped to production — context-dependent, but always worth confirming.
The ones we hear most often, answered before the call.
Not required. AppScan scans the deployed app over HTTP at the URL you give us — no agent, no install in your factory, no LifeTime access, and no source export needed. If a screen, REST endpoint, or server action is reachable from the internet (or a network we can reach), AppScan can reason about it.
Optionally, you can upload an OutSystems solution package (.osp) or application (.oap) to compare source code with the live scan — useful for backend modules that never appear on the wire, flow diagrams, and technical-debt scoring. This is a customer choice, not a prerequisite.
Hosted in the EU. We store the scan reports we generate (findings, response headers, role assignments, action names), per-tenant and isolated. We do not store full response bodies, customer PII, or anything that wasn't necessary to produce the report.
Triage state (fixed / ignored / false positive) and share-link metadata live alongside the reports. See the privacy policy for the data-flow detail and retention windows.
Yes. You give AppScan a custom HTTP request header — name and value of your choice — that we attach to every scan request. Your security team allow-lists that exact value at the WAF (Cloudflare, Akamai, or wherever it sits), so our traffic identifies itself cleanly and gets through while everything else stays behind your usual protections. The value is yours, you rotate it whenever you want, and we just send back what you configured.
Scans can also be routed through a configurable proxy region so the source IP is predictable for IP-based allow-lists. For aggressive bot-protection rules (rate limits, JS challenges), we coordinate the full allow-list with your security team before the first scan.
Most apps scan in 1–3 minutes. Big multi-module apps — think a full banking app with many screens, server actions, and roles — can run up to around 30 minutes. Re-scans are faster: AppScan skips the files that haven't changed since the last scan and only re-reads what's new, so routine re-checks after a release finish well short of that first full run. Your triage state (fixed / ignored / false positive) carries forward too, so the report stays focused on what actually changed.
A probe is a different job and takes longer — see the next question.
Longer than a scan, by design. A scan reads your app once; a probe actively tests it. For each endpoint it sends a normal request first, then a series of crafted ones to see how the endpoint reacts and whether it lets the wrong user in. So the time depends on how many endpoints there are and how much is tested on each — not on the overall size of the app.
Two things keep it predictable. You can cap how fast it sends requests to each app, so a fragile or rate-limited environment is never overwhelmed — and that speed limit, more than raw speed, is usually what sets the runtime. And a re-probe only re-tests the endpoints that changed since last time, so routine checks after a release are much shorter than the first full run.
The probe runs in the background and reports progress as it goes, so you can close the page and come back to it.
Accounts are admin-provisioned today; SSO (SAML / OIDC) is on the roadmap and we'll prioritize it for tenants that ask. Reports can be shared externally with scoped, expiring read-only links — no recipient login required.
A scan is strictly read-only: AppScan issues HTTP requests against your published app, reads the responses, and never modifies configuration in your factory. The full request log for any scan is available to you on request — every URL we hit, every method, every header.
A probe is dynamic testing, so it sends test traffic by design — but it stays on read-safe endpoints unless you say otherwise. Write endpoints are identified and reported as untested rather than fired. Confirming that one of them really is exploitable requires writing to it, so that is a separate, explicit opt-in per scan: it needs two test identities, it can modify data, and we document it for development and staging environments only. It is off unless you turn it on.
Probing is anonymous unless you supply a session. If you want the logged-in surface covered, you provide a scoped test credential you control — pasted from your own browser session, or a dedicated test account you enter. We never use real user credentials, and we will not work around a CAPTCHA, MFA prompt or SSO redirect to get in.
Yes. TOTP (Google Authenticator, Authy, 1Password, hardware keys that emit TOTP) is supported for every account, and enrolment is enforced for all users on an active subscription — they cannot reach the app without completing it. Backup codes are issued at enrolment for lost-device recovery, and trusted devices can be remembered for 30 days and revoked individually.
Trial accounts can enrol at any time from Settings but aren't forced to during the trial, so an evaluation isn't blocked on provisioning an authenticator. Enforcement begins when the subscription becomes active.
SSO (SAML / OIDC) is on the roadmap — see the SSO question above.
Yes. Every login (success and failure), scan start, role change, password reset, API-key issuance, API call, and admin action lands in an append-only audit log. Account Admins see their tenant's slice via Settings → Audit log; AppScan staff have the cross-tenant view for support.
The data is also part of the GDPR export (next question) so you can ingest it into your own SIEM / observability stack on whatever cadence makes sense.
Yes. Settings → Data export (Account Admin only) generates a ZIP of every record AppScan holds for your tenant — your account and users (no password hashes), API-key metadata (no secret hashes), the full audit log, and one file per scan report. The export runs asynchronously — you get an email with a 7-day download link, and the page table shows live status.
Hard-delete on contract end-of-term: we wipe the tenant row, every report payload, every audit entry, and every artifact within 30 days of termination. Available on request before then.
Yes — runtime findings export as SARIF v2.1.0 (the standard GitHub, GitLab, and most IDEs consume). One click from any report. Each finding carries its rule id, CWE reference, severity, evidence excerpt, and the request that triggered it. PDF reports include the same data plus PCI / ISO / SOC 2 control mappings.
Yes. Tokens are aps_<32hex> bearer tokens passed in the Authorization header, with read / write scopes and per-key rate limits; we issue them on request for your tenant. Endpoints today: GET /api/v1/health (scan-status counts), GET /api/v1/reports/{code} (full report JSON), GET /api/v1/findings/{code} (scan findings), GET /api/v1/probe/{code} (probe findings), POST /api/v1/scans (queue a scan) and GET /api/v1/scans/{code} (poll it). The interactive reference lives at /api/docs, backed by an OpenAPI document.
Pricing scales with your factory size — tell us about it and we'll come back with a quote, access details, and answers.