Who are you?
Are login and session controls exposing weaknesses?
Authentication & session testingApplication security, made visible
You can't secure
what you
can't see.
Your application is more than what’s on screen. Aegis discovers the pages, APIs, and inputs behind it—and tests them for security vulnerabilities.
Discover the surface. Understand the risk. Know what to fix.
example.comPages · Routes · APIsParameters · Authentication · Technologies
There’s more beneath the surface.
FROM EXPOSURE TO UNDERSTANDING
- Discover
- Understand
- Test
- Remediate
01 / The unseen application
Your application is bigger
than its homepage.
Behind every screen are services exchanging data, users with different permissions, and inputs that change how things work. Together, these entry points form your attack surface.
example.com
EXAMPLE / STOREShop Account Bag (1)
Everyday essentials.
Anything but ordinary.
Anything but ordinary.
YOUR APPLICATION
What’s underneath
Pages & routesAPIs & GraphQLForms & file uploadsSessions & permissionsParameters & resourcesTechnologies & services
A page can look perfectly normal while the API behind it exposes something it shouldn’t.
You can’t test an entry point
you haven’t discovered.
02 / Security, without the jargon
So, what
is DAST?
Dynamic Application
Security Testing.
In plain English: testing an application while it’s running, from the outside. No source code required.
Aegis interacts with pages, APIs, and inputs to look for behavior that could let someone access data or functionality they shouldn’t.
How it differs from code scanning
Your running application
WebsiteAPIData
Requests to test behaviorResponses to inspect
AEGISDiscover → Test → Gather evidence
Like checking the doors and windows of a building—not just reviewing its blueprints.
An analogy, not a guarantee of complete coverage. Automated testing complements code review and expert assessment.
03 / First, discover
One domain.
A bigger picture.
Start with an application you’re authorized to test. Aegis follows links, explores browser interactions, reads API definitions, and collects the inputs it discovers.
Because a test can only reach what discovery and configuration make available.
Application discoveryIllustrative example · not a live scan
example.com/login → /orders → /api/orders/{id}Method: GET · Parameter: id · Authentication: required
Aegis combines passive discovery, HTML and JavaScript extraction, browser crawling, and API imports. Actual coverage depends on scope, configuration, and application behavior.
01
Look beyond links.
Discover routes in HTML,
JavaScript, and browser traffic.
02
Bring your API definitions.
Import OpenAPI /
Swagger and Postman collections.
03
Keep the scope intentional.
Configure
boundaries, limits, and exclusions.
04 / Then, understand
A URL is a starting point.
Context is the difference.
Finding an endpoint tells you where to look. Its method, inputs, authentication context, and observed behavior help determine what to test. Select a node to look beneath the URL.
GET /api/orders/{id}Authentication: required · Input: idIllustrative relationship: User → Organization → Order
Illustrative application relationships—not a claim that Aegis automatically infers your business model.
Aegis records endpoint and parameter information, fingerprints technologies, and uses configured authentication and active access-control probes. Understanding is built from these signals—not assumed.
05 / Test in context
Ask the questions
an attacker would.
Security testing checks whether the application behaves as intended when requests change. Aegis combines dedicated testing engines with configurable detection templates.
Is this yours?
Can a request reach a resource without the required permission?
Authorization & object-level accessWhat if this changes?
Can an input alter a query, execute a script, or change server behavior?
Input handling & injection testing06 / A small change. A real weakness.
Your order.
Someone else’s data.
Imagine a customer viewing their order. The application knows they’re signed in. But does it check that the order actually belongs to them?
Your order: /orders/12345Change the ID → /orders/12346Another customer’s order is returned: broken access
control.
Fictional example. A successful HTTP status alone does not prove an access-control vulnerability; ownership and response evidence need validation.
The technical issue
Broken access control
The application returns a resource without checking whether the user is allowed to access it.
The security consequence
Unauthorized access
A signed-in user may be able to see another customer’s information.
The business exposure
Customer data at risk
Depending on the data exposed, this could lead to incident costs, regulatory obligations, and lost trust.
07 / Follow the consequence
The question isn’t just “what’s vulnerable?”
It’s “what can
an attacker reach?”
A weakness matters in context. Follow this example from an ordinary customer session to a resource that should be out of reach.
- Public route
- Authenticated user
- Orders API
- Changed order ID
- Missing ownership check
- Another customer’s order
An educational attack path, not a live exploit or a claim of automatic business-impact analysis.
A vulnerability is not just a technical issue.
The resource at the end of the path determines what’s at stake: customer information, account access, financial records, or operational continuity. Your team adds that business context when prioritizing a finding.
08 / The technical view
Built to look
beneath the surface.
Plain-English capabilities first.
The engineering details,
one level deeper.
Coverage depends on enabled engines, templates, credentials, scope, and what the application exposes. No automated scanner finds every vulnerability.
01Web applicationsExplore the pages and interactions behind the interface.
HTML link and form extraction, JavaScript endpoint extraction, and headless Chromium crawling help discover server-rendered applications and client-side routes.
HTML · JavaScript · browser traffic · forms · route discovery
02APIs & GraphQLTest the services that exchange application data.
Import OpenAPI / Swagger definitions and Postman collections. Test discovered HTTP endpoints and their inputs. GraphQL support includes schema-driven input discovery and dedicated security checks where the schema is available.
REST · OpenAPI · Postman · GraphQL
Discovery of a protocol does not imply full security testing of it. This site does not claim active gRPC or WebSocket security coverage.
03Authentication & authorizationLook beyond “logged in” to “allowed access.”
Configure form or JSON login, bearer tokens, cookies, headers, and API keys. When active authorization testing is enabled, Aegis checks anonymous access to discovered resources and selected header, method, and content-type bypass scenarios.
Login · sessions · JWT checks · anonymous replay · access-control probes
IDOR and BOLA describe object-level access-control weaknesses. General cross-user and cross-role comparison is not promised; those scenarios need additional manual assessment. Mutating probes require explicit opt-in.
04Inputs & injectionCheck whether changing a request changes its meaning.
Dedicated engines test SQL, NoSQL, command, and LDAP injection, along with cross-site scripting. Templates extend testing to additional weaknesses such as server-side request forgery and server-side template injection.
Query parameters · forms · headers · JSON bodies · path inputs
Evidence varies by check: response comparisons, timing behavior, browser execution, or out-of-band callbacks when configured.
05Exposure & configurationIdentify information and functionality left exposed.
Technology fingerprints, security-header checks, exposed-file templates, and sensitive-information checks help identify configuration issues and potentially exposed components.
A technology-to-CVE match is a lead for investigation—not proof that the application is exploitable.
09 / From discovery to action
Less “what now?”
More “here’s what to fix.”
A useful finding connects a weakness to an affected endpoint and the evidence behind it. Give security and development teams a shared starting point for investigation and remediation.
-
01
Visibility
Discovered endpoints, inputs, and technology information.
-
02
Findings & evidence
Severity, affected requests, and check-specific evidence where captured.
-
03
Remediation context
Descriptions and guidance where available, alongside finding triage.
-
04
Follow-up testing
Run scans after changes and compare findings. Confirm results in the same authentication and scope context.
Anatomy of a findingIllustrative, not a scan result
High · illustrative severity
Broken access control
GET /api/orders/{id}
- Impact
- A customer may be able to access another customer’s order.
- Evidence
- The same test user receives different owners’ order records when the ID changes. Ownership must be confirmed.
- Remediation
- Enforce a server-side ownership or permission check on every request. Do not rely on an unguessable ID.
- Verify the fix
- Repeat the test with both accounts. Unauthorized requests should not return the other account’s resource.
Status: Open
Review → Fix → Test again
10 / A practice, not a one-time scan
Built into your process.
Not left until the end.
Use Aegis against a running, authorized test environment. Review findings, make changes, and run testing again as your application evolves.
-
01
Discover
Find routes, APIs, and inputs within scope.
-
02
Understand
Collect endpoint, technology, and identity context.
-
03
Test
Run configured security checks.
-
04
Review evidence
Validate and prioritize findings with your team.
-
05
Fix & test again
Rescan after remediation and compare results.
DevelopDeploy to testAEGISReview & fix↳ Repeat as the application changes
Automate with the CLI and REST API, use schedules for recurring scans, and receive configured webhook events. A rescan is not by itself proof that a weakness is fixed.
11 / One picture. A shared purpose.
Different teams.
The same exposure.
Security becomes more useful when everyone can connect the technical finding to the decision they need to make.
For leadership
Know where your
business is exposed.
Turn an abstract security concern into a concrete conversation: what is reachable, what could be exposed, and what your team should investigate next.
Discuss your applicationWhy Aegis
Not just a list of URLs.
A picture you can act on.
Route→Input→Context→Test→Evidence
Aegis brings discovery, technology signals, configured identities, and security testing into one workflow. The point isn’t to send more requests. It’s to make testing—and the findings it produces—more useful.
12 / The practical questions
Let’s talk about
your environment.
How testing runs, where data lives, and how results reach your team are part of the decision. Here’s what the implementation supports—and what needs a conversation.
Deployment
The repository supports a Go binary with an embedded web interface, Docker deployment, and Kubernetes manifests. The web platform uses PostgreSQL.
Confirm with product: commercially available hosting models, managed regions, and support terms.
Authenticated testing
Provide test identities through form or JSON login, or configure tokens, cookies, headers, and API keys. Agree on the accounts, roles, and flows for your application.
Target login support is not a claim of platform SSO or universal identity-provider compatibility.
Automation & integrations
The CLI, REST API, recurring schedules, and signed webhooks provide automation points. The CLI’s severity-based failure threshold can be used in a CI job.
Schedules and webhooks are plan-dependent. No native Jira, Slack, or CI-provider connector is promised here.
Reporting & team workflow
Review and triage findings, compare scans, and export JSON, SARIF, CSV, HTML, or PDF from the platform. Command-line reports also support Markdown and text.
HTML/PDF platform reports are plan-dependent. Evidence varies by check; PDF rendering requires Chromium. Confirm your required artifact in a demo.
Security & privacy
Your scan data deserves
the same scrutiny.
Scan evidence can include request and response content—and sensitive data returned by the target. Use dedicated test accounts and agree on scope, storage, access, retention, and any external testing callbacks before scanning.
Read the Privacy Policy for what we collect, why, and your rights over it.
Two items in that policy are still open, not finalized: which region hosts your data, and a published subprocessor list. Both will be filled in once decided. No certification or compliance claim (SOC 2, ISO 27001, PCI DSS, HIPAA) is made on this site.
A complementary perspective
The code tells one story.
The running app tells another.
Different approaches answer different questions. Aegis adds a view of application behavior to your existing security practice—it doesn’t replace every other tool or expert.
SAST
Look at the code.
Static Application Security Testing examines source code for potential weaknesses without needing the application to run.
DAST / Aegis
Test the behavior.
Discover and test a running application from the outside. Observe how it responds to requests, inputs, and configured identities.
Expert assessment
Challenge the assumptions.
Penetration testers bring human judgment, business-logic analysis, and deeper investigation that automated testing cannot replace.
A few good questions
Let’s make
it clear.
New to application security?
You’re in the right place.
What is DAST?
Dynamic Application Security Testing checks a running application from the outside. It sends requests and examines responses to look for security weaknesses in pages, APIs, and inputs. Aegis combines discovery with this testing.
Why use DAST if we already scan our source code?
Code scanning and running-application testing see different things. DAST can observe deployed configuration, request handling, and behavior under a particular identity. Use it alongside SAST, code review, and expert testing—not instead of them.
Does Aegis test APIs?
Yes. Aegis discovers HTTP API endpoints and supports OpenAPI / Swagger and Postman imports. It also has GraphQL discovery and testing. Coverage depends on available definitions, reachable endpoints, configured authentication, and enabled checks.
Can it test behind a login?
Yes. Target authentication supports form and JSON login, tokens, cookies, headers, and API keys. Supply a dedicated test account and verify the session works for your application. Active authorization probes include authenticated-versus-anonymous comparisons; general multi-account or cross-role testing is not promised.
What vulnerabilities can Aegis identify?
Implemented checks include injection weaknesses, cross-site scripting, authentication and authorization issues, GraphQL security checks, and exposed information or configuration. Some use dedicated engines and others use templates. Explore the capability details for context and limitations.
Does Aegis replace penetration testing?
No. Automated discovery and testing help with repeatable coverage, but expert assessment is still important for business-logic abuse, complex workflows, and validating impact. A finding is a starting point for judgment—not a substitute for it.
Where does Aegis run?
The codebase includes binary, Docker, and Kubernetes deployment options. The web platform requires PostgreSQL. Commercial deployment availability, managed hosting regions, and service commitments need product confirmation.
Can we run it against production?
Active tests send requests that may change data, trigger workflows, or affect performance. Start in a representative non-production environment. Agree on authorization, scope, exclusions, accounts, request limits, and monitoring before considering production. Safety controls reduce risk; they do not make scanning risk-free.
How long does a scan take?
Duration depends on application size, response times, authentication, enabled checks, browser exploration, and scan limits. We do not publish a universal scan-time promise. Evaluate a representative application with the configuration you intend to use.
How does it fit our development workflow?
Use the CLI or API to initiate testing, schedules for recurring scans, and configured webhooks for events. Review and triage findings, make changes, then rescan and compare. Dedicated connectors should be confirmed rather than assumed.
Who is Aegis for?
Security engineers and DevSecOps teams use it to discover and test applications. Developers use findings to investigate fixes. Technology and business leaders use the resulting visibility to ask better questions about exposure and priorities.
Your application. A clearer picture.
See what your
application hides.
Discover your attack surface. Understand your exposure.
Give
your team a clearer path from finding to fix.
Start with a 14-day free trial. Full product access, no payment method required. Explore discovery, authenticated testing, and evidence on your own application before you commit to a plan.
Visit the existing Aegis access portal