OBSERVA emblem

OBSERVA

Ethical and legal boundary

Use only on systems, domains and accounts you own or are explicitly authorized to assess.

No brute force, fuzzing, exploitation, credential collection, bypass testing, stealth logic or unauthorized scanning is implemented.

Network and service views are mock-only unless a user provides an owned target and confirms permission.

Analyzer checks are limited to low-impact HTTP metadata, security headers and public discovery hints.

Authorized use only

WPScan

A WordPress security assessment tool.

Authorized WordPress hygiene review for plugins, themes, versions and configuration risk.

Safe use cases

  • - Plugin/update hygiene
  • - Admin hardening checklist
  • - Backup and least privilege review

What not to do

  • - Do not enumerate or test third-party sites
  • - Do not brute force logins
  • - Do not exploit findings

Legal boundary: Use only on WordPress sites you own or are contracted to assess.

Data sensitivity: Site technology and user exposure details can be sensitive.

OBSERVA integration: Represent WordPress checks as manual safe checklist items, not executable scans.

Authorized use only

Browser DevTools

Built-in browser inspection tooling for network, storage and page metadata.

Capture HAR, headers and page behavior on owned or authorized sites.

Safe use cases

  • - Header review
  • - Evidence capture
  • - Cookie flag inspection
  • - Performance observation

What not to do

  • - Do not extract tokens or private data from others
  • - Do not bypass application controls

Legal boundary: Use only on assets, data and investigations you own or are explicitly authorized to assess.

Data sensitivity: HAR files can include cookies, URLs and identifiers.

OBSERVA integration: Evidence capture checklist and web analyzer guidance.

Authorized use only

Security.txt / robots.txt / sitemap inspection

Low-impact checks of public metadata files.

Understand disclosure channels, crawl hints and public site structure.

Safe use cases

  • - Security contact validation
  • - Sitemap presence
  • - Public exposure checklist

What not to do

  • - Do not aggressively crawl
  • - Do not treat robots.txt as authorization to probe

Legal boundary: Inspect owned or authorized websites; respect terms and robots guidance.

Data sensitivity: Public files may still reveal operational structure.

OBSERVA integration: Safe analyzer discovery panel.

Foundational

Reconnaissance basics

Understand what public information about your own systems may expose.

Theory

Reconnaissance is the structured collection of public metadata, service information and documentation before deeper assessment.

Safe lab

Use a local demo site or a domain you own. Record only headers, DNS records and public pages you are authorized to review.

What to check

  • - Public DNS records
  • - Security.txt
  • - Technology exposure
  • - Unexpected staging references

How to mitigate

  • - Remove stale records
  • - Publish security contact paths
  • - Minimize exposed metadata
  • - Keep asset inventory current

Red flags

  • - Unknown subdomains
  • - Staging portals indexed publicly
  • - Old admin interfaces

Authorized tools only

  • - Browser devtools
  • - dig/nslookup
  • - securityheaders.com-style checks
  • - Asset inventory

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

Network fundamentals

Build enough network literacy to document assets, routes, DNS and service ownership.

Theory

Networks rely on addressing, routing, DNS, ports and transport protocols. Defenders map these to understand exposure.

Safe lab

Inspect your local router page, localhost services and a private lab VM. Do not scan networks you do not own.

What to check

  • - Router firmware
  • - DNS resolver
  • - Known devices
  • - Documented services

How to mitigate

  • - Patch routers
  • - Change default passwords
  • - Disable unused services
  • - Segment guest devices

Red flags

  • - Unknown DHCP clients
  • - Unmanaged DNS
  • - Open admin services

Authorized tools only

  • - Router admin UI
  • - OS network settings
  • - Local firewall logs

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

DNS, HTTP, TLS and headers

Understand how web trust, transport encryption and browser policies reduce risk.

Theory

DNS locates services, TLS protects transport, HTTP headers instruct browsers how to enforce security boundaries.

Safe lab

Analyze headers on localhost or an owned website using only GET/HEAD requests.

What to check

  • - HSTS
  • - CSP
  • - X-Frame-Options
  • - Referrer-Policy
  • - Certificate expiry

How to mitigate

  • - Deploy HSTS
  • - Use CSP carefully
  • - Automate certificate renewal
  • - Limit referrer leakage

Red flags

  • - Expired certificates
  • - Missing HSTS
  • - Unsafe inline scripts

Authorized tools only

  • - Browser devtools
  • - curl -I on owned targets
  • - Certificate transparency monitors

Do not use without permission. Authorized lab and owned-system assessment only.

Intermediate

OWASP Top 10

Translate common web application risk classes into safe review checklists.

Theory

OWASP categories describe patterns of weakness, not instructions to attack systems.

Safe lab

Use intentionally vulnerable local labs only, then document mitigations and detection signals.

What to check

  • - Access control boundaries
  • - Authentication flows
  • - Input handling
  • - Logging coverage

How to mitigate

  • - Server-side authorization
  • - Parameterized queries
  • - Secure defaults
  • - Monitoring

Red flags

  • - IDOR patterns
  • - Verbose errors
  • - Missing audit trails

Authorized tools only

  • - OWASP ASVS
  • - Threat modeling templates
  • - SAST/DAST in authorized CI

Do not use without permission. Authorized lab and owned-system assessment only.

Intermediate

Web vulnerability theory

Learn how weaknesses happen so you can prevent them without executing real attacks.

Theory

Most web issues arise from broken trust boundaries, unsafe input handling, weak state management or insecure configuration.

Safe lab

Use static code samples and local intentionally vulnerable apps. Keep exercises offline or private.

What to check

  • - Trust boundaries
  • - State changes
  • - Sensitive data flow
  • - Error handling

How to mitigate

  • - Validate inputs
  • - Encode outputs
  • - Use framework protections
  • - Add tests for abuse cases

Red flags

  • - Client-side-only authorization
  • - Unescaped output
  • - Unbounded upload handling

Authorized tools only

  • - Code review checklists
  • - Unit tests
  • - OWASP Cheat Sheets

Do not use without permission. Authorized lab and owned-system assessment only.

Intermediate

Secure authentication

Reduce account takeover risk with strong authentication and recovery controls.

Theory

Authentication must resist password reuse, phishing, recovery abuse and session replay.

Safe lab

Model login and recovery flows on a toy app without real user data.

What to check

  • - MFA type
  • - Recovery paths
  • - Rate limits
  • - Session invalidation

How to mitigate

  • - Passkeys
  • - Hardware security keys
  • - Step-up auth
  • - Recovery review

Red flags

  • - SMS-only MFA for admins
  • - Unknown recovery email
  • - No session inventory

Authorized tools only

  • - IdP logs
  • - Password manager audit
  • - Auth flow diagrams

Do not use without permission. Authorized lab and owned-system assessment only.

Intermediate

Session management

Document and improve how sessions are created, rotated, revoked and monitored.

Theory

Sessions are bearer trust artifacts and should be scoped, rotated and invalidated after risk events.

Safe lab

Review cookie attributes on your own local app and document expected behavior.

What to check

  • - HttpOnly
  • - Secure
  • - SameSite
  • - Rotation on privilege change

How to mitigate

  • - Shorten risky sessions
  • - Revoke on password change
  • - Bind to device signals carefully

Red flags

  • - Long-lived admin sessions
  • - No logout-all option
  • - Missing Secure cookie flag

Authorized tools only

  • - Browser devtools
  • - IdP session dashboard
  • - Threat modeling

Do not use without permission. Authorized lab and owned-system assessment only.

Intermediate

Access control

Verify users can only access the objects and actions they are authorized for.

Theory

Access control must be enforced server-side for every object and action.

Safe lab

Write unit tests against local authorization functions using mock users and objects.

What to check

  • - Object ownership
  • - Role boundaries
  • - Admin routes
  • - Audit logs

How to mitigate

  • - Centralize policy checks
  • - Deny by default
  • - Test negative cases
  • - Review role grants

Red flags

  • - Predictable IDs without checks
  • - Hidden buttons as security
  • - Overbroad admin roles

Authorized tools only

  • - Authorization test suites
  • - Policy-as-code
  • - Access reviews

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

Input validation

Keep untrusted input from crossing boundaries unsafely.

Theory

Validation defines acceptable shape and constraints; output encoding prevents browser interpretation problems.

Safe lab

Validate sample forms locally with harmless strings and schema tests.

What to check

  • - Schema validation
  • - Length limits
  • - File type rules
  • - Output encoding

How to mitigate

  • - Use schema libraries
  • - Parameterize data access
  • - Normalize inputs
  • - Reject unexpected fields

Red flags

  • - Raw HTML rendering
  • - Unbounded text fields
  • - Dynamic query construction

Authorized tools only

  • - Zod
  • - Framework validators
  • - Unit tests

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

Logging and monitoring

Create useful audit trails without over-collecting sensitive data.

Theory

Logs should show security-relevant events, context and outcomes while protecting privacy.

Safe lab

Design an event taxonomy for a mock application.

What to check

  • - Login events
  • - Privilege changes
  • - Export actions
  • - Retention rules

How to mitigate

  • - Avoid secrets in logs
  • - Alert on risky changes
  • - Define retention
  • - Centralize review

Red flags

  • - No audit log for admin actions
  • - Tokens in logs
  • - No alert ownership

Authorized tools only

  • - SIEM dashboards
  • - Structured logging
  • - Runbooks

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

Incident response basics

Prepare calm, evidence-preserving steps for suspicious activity.

Theory

Response work follows preparation, identification, containment, eradication, recovery and lessons learned.

Safe lab

Run a tabletop exercise using mock alerts and export an incident timeline.

What to check

  • - Timeline
  • - Evidence quality
  • - Affected accounts
  • - Containment steps

How to mitigate

  • - Preserve evidence
  • - Rotate credentials from clean devices
  • - Revoke sessions
  • - Communicate clearly

Red flags

  • - Deleting evidence first
  • - Untracked changes
  • - No owner for decisions

Authorized tools only

  • - Incident template
  • - Ticketing system
  • - Secure evidence storage

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

Responsible disclosure

Report vulnerabilities ethically, legally and constructively.

Theory

Responsible disclosure minimizes harm by reporting issues through authorized channels and avoiding data access.

Safe lab

Write a mock disclosure report for a toy vulnerability in a local lab.

What to check

  • - Scope
  • - Impact
  • - Reproduction safety
  • - Contact channel

How to mitigate

  • - Use security.txt
  • - Avoid sensitive data
  • - Share minimum proof
  • - Respect timelines

Red flags

  • - Testing outside scope
  • - Accessing real user data
  • - Public pressure before coordination

Authorized tools only

  • - Security.txt
  • - Disclosure templates
  • - Bug bounty scope pages

Do not use without permission. Authorized lab and owned-system assessment only.

Foundational

Legal and ethical boundaries

Keep security learning permission-based and harm-reducing.

Theory

Authorization, proportionality and data minimization are the line between learning and abuse.

Safe lab

Use local labs, CTFs and owned assets. Keep written permission for any real assessment.

What to check

  • - Written scope
  • - Allowed methods
  • - Data handling
  • - Stop conditions

How to mitigate

  • - Get authorization
  • - Use low-impact checks
  • - Document activity
  • - Stop if unsure

Red flags

  • - No written permission
  • - Requests to bypass controls
  • - Collection of secrets

Authorized tools only

  • - Rules of engagement
  • - Lab environments
  • - Ethics checklists

Do not use without permission. Authorized lab and owned-system assessment only.