The assessor portal's browser-visible response headers name a common web stack. How should that fact be handled in PORP-scope website OSINT?
Select an answer to reveal the explanation.
Short Explanation
A stack header in the browser is like a brand sticker on a public kiosk — you can read it while walking past. Write the clue down. Turning that into a scan or an exploit against the assessor portal is pentest work, not PORP.
Full Explanation
When the assessor portal’s browser-visible response headers name a common web stack, that fact should be handled by noting the already-visible public stack clue in notes and stopping short of scanning or attacking the city’s production site. Headers readable in a normal browser session are passive OSINT. Launching an intrusive vulnerability scan of the production civic site and calling it OSINT fails; scanning is a separate authorized security activity, not PORP collection. Weaponizing the header by running exploit modules against the named CMS fails as offensive action. Stripping the headers from the city’s production servers as the OSINT deliverable fails; configuration change is an IT task, not the researcher’s collection product. Exam caveat: stack clues inform defensive conversations but do not authorize exploitation. Operational check: record header names and values with URL and date; pass the observation to civic IT security if relevant; do not scan or exploit the assessor portal under an OSINT label. In municipal practice, record the rationale in the case file so future staff know which control was chosen and which failure modes the rejected options would create for city services.