Built for OutSystems

Find OutSystems risks before attackers do.

Generic security scanners don't understand OutSystems factories. AppScan Studio does — we catch what code review missed before your customers do. Pages reachable without login. Customers seeing each other's data. Junior staff seeing executive screens. Last release's fix quietly broken in this one. Built for the developers shipping the code and the PMs shipping the project.

1,000+ production release reports across real OutSystems factories
URL-based scanningNo source code, no agents, no install
Read-only analysisWe never modify your apps or environment
Per-tenant isolationReports scoped to your client, never crossed
Expiring share links7-day, scoped, revocable on demand
Full audit trailEvery login, scan, and triage logged
EU-hosted · GDPR-alignedOperated from Portugal under QUICKSYNC, UNIPESSOAL LDA
// How it works

Paste a URL. Get a security report.

No source code, no agents. AppScan works against the published app the way an attacker would see it.

// 01 — Scan

Drop in the app URL

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.

// 02 — Classify

Findings, ranked

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.

// 03 — Triage

Fix what matters

Mark findings as fixed, ignored, or false positive. Compare against the previous release to see what's new. Share scoped, expiring links with stakeholders.

// See it in action

Built to be read at a glance.

The dashboard view of every scan, every status, every release — designed to be skimmed in seconds before a deploy.

AppScan dashboard screenshot

Every release at a glance

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.

Want to see a finished report? Open the sample report 

// The objection

Doesn't code review already catch this?

Sometimes. Until your factory grows past one reviewer's working memory, or the same legacy debug code surfaces in every release for the fifth quarter running.

No memory across releases

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.

Diffs findings, not code

Code review tools show what changed. AppScan shows what's still risky — including code that didn't change but is exposed differently because something else around it did.

Sees the whole factory

A reviewer sees the PR they're assigned. AppScan walks every screen, every server action, every module — including the modules nobody actively owns and the ones a junior dev shipped six months ago.

Same rules every time

Alice catches role misuse. Bob misses it because he's tired. The next reviewer doesn't know what to look for. AppScan applies the same curated pattern set on every scan — no off days.

// The other objection

What about AI Mentor's security checks?

Different layer. AI Mentor reviews your source at design time — patterns and suggestions inside Service Studio. AppScan tests the deployed app from the outside — what's actually exposed once a release is published. Both are useful; they don't see the same things.

Source-time vs. runtime

Source-time tools read what you wrote. AppScan reads what your customers get — the live URL, the published role, the response your app actually returns today. Same code can ship differently across environments; only the runtime sees that.

Per-release diffing

Static reviewers 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.

Independent second opinion

A scan written outside your IDE is an independent check on the assumptions inside your IDE. If something says it's "Registered" but the deployed endpoint answers anonymously, AppScan catches the gap. Defense in depth is layered on purpose.

// Capabilities

Everything you need to ship safely.

Designed around the way OutSystems teams actually work — release cycles, modules, and PMs who need a plain-English summary.

Screen role audit

Flags screens left open to Anonymous or stuck on generic Registered — the access-control gaps that turn into data leaks.

IDOR exposure

Spots endpoints that take internal IDs without ownership checks — the pattern attackers use to enumerate other users' records.

Action name classification

Server-action names are scored against curated Dangerous and Suspicious pattern sets — code that always deserves a second pair of eyes.

Response-header analysis

CSP gaps, cookie-flag issues, missing security headers. Each finding links to a guide explaining the why and the fix.

Version diff & AI changelog

Compare two scans. Get a dev-facing changelog and a PM-friendly summary — engineers and stakeholders read the same release notes.

New-finding alerts

Per-release diffing surfaces only what wasn't flagged last time and isn't already triaged. No alert fatigue.

Action triage

Mark findings fixed, ignored, or false positive. Triage state is shared and silences resolved items on future scans.

Expiring share links

Send a 7-day, scoped read-only link to one specific report. No login needed for the recipient.

Network controls

Custom headers (Akamai, Cloudflare bypass) and proxy-country selection — for apps behind firewalls or geo-restricted.

// Action name patterns

Two ranked tiers of name-based hints.

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.

Dangerous

Red

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.

Suspicious

Amber

Naming and shape patterns that point to code which probably shouldn't have shipped to production — context-dependent, but always worth confirming.

// Frequently asked

Procurement & security questions.

The ones we hear most often, answered before the call.

Do you need source code, OAP files, or access to our OutSystems environment?

No. AppScan scans the deployed app over HTTP at the URL you give us. No agent, no install in your factory, no LifeTime access, no source export. If a screen, REST endpoint, or server action is reachable from the internet (or a network we can reach), AppScan can reason about it.

Where is data hosted, and what gets stored?

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.

Our apps sit behind Cloudflare / Akamai / a WAF. Can you still scan them?

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.

How long does a scan take?

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. Scan time scales with how much there is to walk, not with whether the release is new or unchanged: re-scans take roughly the same time as the first scan. Your triage state (fixed / ignored / false positive) carries forward, so the report stays focused on what actually changed.

Do you support SSO, and is self-hosting an option?

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.

For self-hosting (regulated industries, sovereignty requirements), reach out via the contact form. It's not a default deployment but it's supported on a case-by-case basis.

What's the read-only guarantee, exactly?

AppScan only issues HTTP requests against your published apps and reads the responses. We never call write/mutating endpoints with destructive payloads, never authenticate as a real user against your environment, and never modify 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.

See what's exposed in your next release.

Pricing scales with your factory size — tell us about it and we'll come back with a quote, access details, and answers.

Reports stay scoped to your tenant — never shared across clients. We use OpenAI for the optional AI changelog generation; everything else stays inside AppScan.

Or email us at [email protected]