Authorisation and scope
Assets, environments, methods, exclusions, time windows and stop conditions are agreed in writing. Permission on one system does not authorise testing a third-party service.
Method · Application, API & Azure security
Risk-based checks. Evidence-backed conclusions.
A useful audit explains what was reviewed, what remains unknown and how to verify fixes. This page sets out the framework and practices proposed for INOBIC engagements.
Version 1.0 · 7 November 2026 · Selected during scoping; no certification or overall compliance claimed.
Before testing: agree on the framework
Only the access and data needed
Request only what is needed; prefer read-only access and synthetic data. Channels, recipients and retention periods are agreed before receiving sensitive data.
Business risks and limitations
Identify sensitive flows, trust boundaries and assumptions. Distinguish documentation review, code reading, configuration review and expressly authorised active tests.
A checklist tailored to the engagement
These 22 checks form an INOBIC checklist to adapt. They do not mean every engagement covers all technologies or that all checks have already run on our website. Methods, reference requirements and available resources are specified during scoping.
Scoping and evidence
GOV-01 · Authorisation and limits
Record assets, versions, accounts, methods, exclusions, third-party rights, contacts and stop conditions. No implicit scope extension.
Expected evidence: Dated scope and written authorisation; internal references without secrets.
GOV-02 · Data and channels
Agree on permitted data, channels, recipients, external/AI tools, retention and return or deletion.
Expected evidence: Agreed handling arrangements, evidence limited to what is necessary, and separate approval before publication.
GOV-03 · Architecture and assumptions
Identify sensitive flows, trust boundaries and business scenarios; distinguish code review, configuration and active testing.
Expected evidence: Versioned diagram or inventory and a list of limitations.
GOV-04 · Check traceability
Link each check to its component/version, method, date, result and evidence; never treat lack of access as success.
Expected evidence: Check record and references to redacted evidence.
Applications and .NET
APP-01 · Resource-level authorisation
Check owner, organisation and role server-side; include allowed, denied and missing-identity cases.
Expected evidence: Positive and negative tests on test resources, with no data returned on denial.
APP-02 · Authentication and sessions
Depending on the mechanism: token validation, lifetime and revocation, cookies and sensitive-operation protection; distinguish authentication from authorisation.
Expected evidence: Reviewed configuration and test scenarios defined during scoping.
APP-03 · Inputs and outputs
Review validation, context-aware encoding, parameterised queries and file/redirect handling along actual code paths.
Expected evidence: Code-linked findings and targeted tests without production data.
APP-04 · Failures and confidentiality
Test behaviour without JavaScript or permission, or when a service is unavailable; look for data in URLs, errors and logs.
Expected evidence: Tests under failure conditions and checks for sensitive data in outputs.
APP-05 · Runtime and dependencies
Identify supported versions, direct/transitive dependencies and applicable advisories; distinguish alerts, exposure and exploitability.
Expected evidence: Dated inventory, advisory sources and triaged results; state limitations if scanning is unavailable.
APIs and integrations
API-01 · Operation scope
Check access to objects, properties and sensitive functions against business roles.
Expected evidence: Access matrix and authorised negative test cases.
API-02 · Request contracts and limits
Review request validation, pagination, quotas and errors; no load testing without separate agreement.
Expected evidence: Configuration and bounded tests using synthetic data.
API-03 · External services
Review permitted outbound destinations and response data; do not assume third-party APIs are trustworthy.
Expected evidence: Integration paths reviewed without contacting out-of-scope third parties.
Azure and identities
AZ-01 · Effective permissions
Review direct/inherited roles and business needs; avoid exposing identities and identifiers in public evidence.
Expected evidence: Redacted permission findings; approved fix without administrative lockout.
AZ-02 · Secrets and workload identities
Prefer managed identities where suitable; review secret access without unnecessarily extracting values.
Expected evidence: Required metadata and permissions; rotation procedure if exposure is confirmed.
AZ-03 · Exposure and networking
Review public/private access and restrictions for in-scope resources. A public website is not inherently a misconfiguration.
Expected evidence: Configuration compared against needs and change impacts assessed.
AZ-04 · Logs and alerts
Check available events, recipients, alerts and retention; do not infer a complete lack of logging from a partial review.
Expected evidence: Configuration evidence, or an unverified status identifying missing access.
DevSecOps and remediation
CI-01 · Pipeline permissions
Review job permissions, branches and approvals; isolate untrusted contributions from deployment secrets.
Expected evidence: Reviewed pipeline configuration and access scenario.
CI-02 · Automated checks
Choose SAST, dependency analysis (SCA) and secret-detection tools suited to the stack. Assess alerts and record each exception with an owner and a deadline.
Expected evidence: Dated reports and documented handling of false positives. Only report a tool as used if it was actually run.
FIX-01 · Proportionate remediation
Link the change to the root cause, keep the diff small, plan review and rollback; do not broaden privileges to resolve a symptom.
Expected evidence: Diff and validation criteria; reviewer identity to be recorded.
FIX-02 · Verification
Rerun the initial scenario and allowed, denied and degraded cases; distinguish unit, integration, browser and production testing.
Expected evidence: Before-and-after results on identified versions, with coverage limits.
FIX-03 · Publication and integrity
Check intended files, keep private evidence out of the package and verify behaviour after publication.
Expected evidence: Manifest, targeted production checks and rollback plan.
FIX-04 · Closure and residual risks
List items not retested, accepted risks and open actions; agree on access revocation and data handling.
Expected evidence: Handover and owner decisions; distinguish accepted risk from fixed risk.
Make every conclusion verifiable
Record the component and version, method, date, reviewer, supporting evidence and limitations for each result. Automated tools flag potential issues; their alerts need assessment before they can support an audit conclusion.
Verified / finding confirmed
“Verified” applies only to the documented criterion and scope. A confirmed finding also describes required conditions and business impact.
Partial or unverified
Missing access, scenarios that were not run and insufficient evidence remain documented in the report. The absence of alerts does not establish the absence of vulnerabilities.
Not applicable
Exclusions must be justified by the architecture or scope, not used to hide a difficult check.
Assess, fix, then verify
- 01
Assess the finding
Separate observed facts, assumptions and risks. Assess preconditions, exposure and business impact. Any CVSS score must specify its version, vector and assumptions; it does not replace business prioritisation.
- 02
Fix the root cause
Propose a proportionate, reviewed change with validation criteria and rollback. Each exception names an owner, reason and review date.
- 03
Rerun the scenarios
Test the initial flaw, expected behaviour and denied or degraded modes. Specify the tested layer: unit, integration, browser or production. A fix is verified only on the version actually retested.
- 04
Report limitations
List residual risks, open issues and items not retested. An owner’s risk acceptance remains distinct from a fix. Close the engagement according to agreed access and data arrangements.
Protect evidence and communications
Limit screenshots and logs to what is needed; use synthetic test markers and redact secrets, identities and infrastructure references in public versions. Keep originals only in the agreed location with limited access.
External or AI services handling confidential information require prior agreement. Publishing a case needs separate authorisation and export review. Hashes help check evidence integrity; they are not independent attestation.
Applying the method to INOBIC: what the evidence shows
- Form failure behaviour: issue reproduced locally, fix tested with and without JavaScript, then normal flow checked on the published website.
- Verification: targeted unit and browser tests, HTTP checks and deployment integrity. This does not cover every browser or scenario.
- Azure permissions: targeted review of applicable roles; least-privilege issue remains open. No tenant-wide compliance is claimed.
- Azure logging: The review did not establish the operational logging policy; this remains to be verified.
- .NET authentication and business APIs: outside the scope of this static website. The educational lab is presented separately.
This summary relates existing evidence to our method; it does not retroactively turn the targeted review into a full ASVS, Azure or SSDF audit.
Read the real finding and its fixes →Frameworks: guidance, not accreditation
Official sources consulted on 7 November 2026. Relevant versions and selected requirements are recorded for each engagement. The references below are thematic; no exhaustive mapping, affiliation or certification is claimed.
- OWASP ASVS 5.0.0
Select application verification requirements; specify requirements and version in scope without claiming an unevaluated full level.
- OWASP API Security Top 10 — 2023
Identify API risk categories. A risk list is not an exhaustive testing protocol.
- Microsoft — ASP.NET Core 10 security
Adapt checks to the runtime version and mechanisms actually used.
- Azure Well-Architected — security checklist
Review security choices and trade-offs for the authorised workload without expanding to the entire tenant.
- NIST SSDF — SP 800-218, version 1.1
Organise secure development and vulnerability response according to risk.
Documents to prepare an engagement
Blank templates to customise for your engagement. Every check starts as “unverified”; no authorisation, evidence or signature is prefilled.
Scope your audit needs