App Misconfigurations

App Misconfigurations is the focused queue for application-layer security weaknesses on your internet-facing web apps: missing or weak security headers, sensitive files and paths exposed to anonymous users, applications still running default credentials, internal-only applications reachable from the public internet, origin servers that bypass your WAF, and expiring domains. It is a curated slice of the same engine that powers Alerts, narrowed to the findings an application security or web team owns — so you can triage app hygiene without wading through network, DNS, certificate, and dark-web findings.

Overview

The page is a single sortable table of misconfiguration findings, one row per detected weakness. Working top to bottom:

• A page header showing the total count and an Export button.
• A Bookmarked filter chip that toggles the list down to items you have starred.
• A filter bar with category filters (Title, Risk, Status, Assignee, Source, Date) plus a free-text search.
• The findings table with a select-all checkbox, a bookmark star, and the columns Title, Risk, Relevance, Status, Assigned To, Source, and Created. Each row has an inline comment thread; clicking a row opens its detail.
• Pagination at the bottom (25 rows per page).

Two things to understand before you use the page: every finding carries two independent statuses (what the scanner currently sees versus what your team decided), and the queue is deduplicated and auto-reopened so the same weakness never appears twice. Both are explained below.

How it works

These are the mechanics you cannot read off the screen.

What counts as an "app misconfiguration"

This module is not a separate scanner. It is the Alerts data store filtered to the application-alert finding types — the subset of ShadowMap checks that target web applications rather than network services, DNS, or TLS. The detection sources that feed this queue are:

Finding type	What it detects
At Risk Applications	Applications flagged as risky by HTTP analysis — exposed admin interfaces, dangerous server responses, risky technologies, and similar app-level red flags.
WAF Bypass (Origin)	An origin server reachable directly, bypassing the CDN/WAF in front of it. An attacker who finds the origin IP can hit the app without ever passing your web application firewall.
Internal Application Exposure	An application intended to be internal-only (admin panels, staging, internal tooling) that is answering on the public internet.
Applications Vulnerable to Default Credentials	A web application whose login still accepts vendor/default credentials (HTTP-based default-credential check).
Missing Security Headers	Responses missing hardening headers (e.g. HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options).
Sensitive Files/Path Discovered	Path/directory brute-forcing surfaced a sensitive file or path — backups, config files, .git, admin endpoints, etc.
Possible Website Defacement	The defacement checker detected content changes consistent with a defacement. (The dedicated view is Defacements.)
Directory Scan - At Risk Applications	Directory scanning surfaced an at-risk application or exposed listing.
Expired/Expiring Domains	A domain associated with your apps has expired or is approaching expiry — a lapse that can lead to loss of control or takeover.

Why this grouping exists

Findings are organised by the team that fixes them. App misconfigurations are owned by web/app security; open ports and exposed services by infrastructure/network; certificate and DNS hygiene by their respective owners. The same underlying alert can appear in Alerts (the union of everything) and here (the application slice) — it is one record, surfaced in two views, not a duplicate.

Two status axes, never conflated

Every finding has two separate states, and the product keeps them apart:

• Scanner status — what ShadowMap's scanners currently observe: New (just discovered), Open (still detected in the latest scan), or Closed (no longer detected). This is machine-driven; you do not set it.
• Analyst response — what your team decided: Needs Review (the default until someone triages it), Investigating, Accepted Risk, or Closed. This is the workflow axis you control.

The word "Closed" exists on both axes and means different things. A scanner-Closed finding is simply gone from the latest scan — the header was added, the path was removed, the origin was firewalled. An analyst-closed finding is one a human dispositioned. A finding can be scanner-Open and analyst-Accepted Risk at the same time (the weakness is real and ongoing, but you have decided to live with it), or scanner-Closed and still awaiting review (the scanner no longer sees it, but nobody confirmed the fix). Keeping the axes separate is what lets you tell those apart.

Risk levels

Risk is derived from each finding's numeric risk score (0–10). The thresholds are:

Risk	Score	Meaning
High	8 – 10	Critical exposure; act immediately
Medium	5 – 7	Significant risk; address promptly
Low	2 – 4	Minor risk; address when convenient
Informational	0 – 1	Awareness only; no immediate action

By default the list sorts by Created (newest first). You can re-sort by Risk to push the highest-severity weaknesses to the top.

Deduplication and auto-reopen

ShadowMap collapses repeat detections of the same weakness into one finding. The identity is a hash of the finding's join keys — IP, host, port, path, source, and title. When a later scan re-detects the same weakness on the same app, ShadowMap updates the existing record (refreshing its last-detected timestamp) instead of creating a second row.

If a finding was previously closed and the same weakness resurfaces in a new scan, it is reopened — the scanner status flips back to detected. A reopened app misconfiguration almost always means the remediation was incomplete or the issue recurred (a header was dropped again in a redeploy, a sensitive path came back, an origin was re-exposed). This is why the queue stays trustworthy over time: a clean list means the weaknesses are genuinely gone, not just stale.

Understanding the data

Columns

Column	Description
Title	The human-readable finding name, e.g. "Missing Security Header: Strict-Transport-Security" or "Internal Application Exposed". Always shown.
Risk	High / Medium / Low / Informational, colour-coded (see thresholds above).
Relevance	A relevance score badge indicating how material the finding is likely to be for your environment, used to surface the findings most worth your attention.
Status	The current workflow/scanner status text for the finding.
Assigned To	The team or user the finding is routed to, or – if unassigned.
Source	The detection source/finding type that produced the row (see the table in How it works).
Created	When the finding was first recorded, shown as a relative time (e.g. "3 days ago").

Columns other than Title can be shown or hidden; your selection is remembered in the browser for next time.

The affected asset

Each finding is tied to a specific application target. In the detail view you can see the host, IP, and port the weakness was found on, along with enrichment such as the hosting provider (ASN) and geolocation where available. This is what tells you which app to fix — a "Missing Security Headers" finding on payments.example.com is a very different priority from the same finding on a marketing microsite.

Filtering and search

The filter bar lets you narrow the queue by:

• Title — the specific finding name.
• Risk — High, Medium, Low, Informational.
• Status — workflow/scanner state.
• Assignee — the team or user a finding is routed to.
• Source — the detection finding type (e.g. Missing Security Headers, WAF Bypass).
• Date — when findings were created.

The search box is a free-text match over finding fields. The Bookmarked chip is a client-side toggle that restricts the visible rows to items you have starred, so you can build an ad-hoc working set without changing your filters.

Triage workflow

A practical first pass: filter Source = Internal Application Exposure and Source = WAF Bypass (Origin) and sort by Risk descending. Those two finding types represent apps that should not be publicly reachable at all (internal exposure) or that defeat a control you are paying for (origin bypass), and they tend to be the highest-leverage fixes in this queue.

Taking action

From the list you can:

• Bookmark a finding (the star) to add it to your personal working set.
• Select rows (checkbox, or select-all in the header) for bulk operations.
• Comment on a finding inline — the comment thread on each row supports saved comment templates for consistent triage notes.
• See who owns each finding in the Assigned To column, and filter by Assignee to isolate a given team or user's slice.
• Export the current view to a file for reporting or offline work; the export respects your active filters and search.

Opening a finding (click the row) brings up its detail, where you can review the affected asset, the evidence, and the full history, and disposition it. Because app misconfigurations share the Alerts backend, the same status workflow, assignment, SLA tracking, and sharing/integration actions available in Alerts apply here.

Keyboard shortcuts

The list supports keyboard-driven triage:

Key	Action
j / ↓	Next row
k / ↑	Previous row
Enter	Open the focused finding
Space	Toggle selection
s	Toggle bookmark
Esc	Close the detail drawer
?	Show the shortcut help overlay

Common questions

How is this different from the main Alerts queue? It is the same data, filtered. App Misconfigurations shows only the application-layer finding types — missing headers, exposed paths, default credentials, internal/origin exposure, and related app weaknesses. Alerts shows the union of all finding types across every module. Use this view when an app-security owner wants their slice without network, DNS, certificate, or dark-web noise.

Why does a finding I "fixed" keep coming back? Because the same weakness was detected again on a later scan, the record auto-reopens. A reopened app misconfiguration means the fix did not hold — a hardening header was lost in a redeploy, a sensitive path was restored, or an internal app was re-exposed. Treat a reopen as a signal that the remediation needs to be made durable, not just applied once.

A finding shows as Closed but I never touched it. What happened? That is the scanner status, not an analyst disposition. The scanner simply no longer detects the weakness — the exposure is gone from the latest scan. It is a good outcome, but it is independent of whether your team formally reviewed and closed it.

What does "WAF Bypass (Origin)" actually mean? ShadowMap found a way to reach the application's origin server directly, without going through the CDN or web application firewall in front of it. Any protections enforced at the WAF (rate limiting, request filtering, bot management) can be skipped by an attacker who hits the origin, so these are worth prioritising.

Can I focus on the findings a given team owns? Yes. Filter by Source and Title to carve out a specific class of weakness, and by Assignee to narrow to the team or user a finding is routed to. Assignment, SLA policies, and notifications carry over from the shared Alerts backend.

Where do defacement findings live — here or in their own view? Defacement detections can surface here under "Possible Website Defacement," but the dedicated, full-context view is Defacements.

Related

• Alerts — the unified triage queue this module is a filtered slice of; shares the same status workflow, risk model, assignment, and export.
• Web Applications — the inventory of discovered web apps these misconfigurations are found on.
• SSL Certificates — certificate and TLS hygiene (handled as a separate finding class from app misconfigurations).
• Open Ports and Network Services — the network-layer counterparts: exposed ports and services rather than application weaknesses.
• Defacements — dedicated view for website-defacement findings.
• Technology Stack — the technologies fingerprinted on your apps, useful context when prioritising a misconfiguration.