Sourced / Security
Find the risk.
Make the fix clear.
Security testing for web applications, APIs and AI apps. Give your team the evidence to set priorities, fix issues and check the result.
Web applications / APIs / AI systems
A user can read another workspace's record
The API accepts a record ID without checking that the signed-in user belongs to its workspace.
GET /records/record-bWorkspace B recordEvidence
An authorized test account receives a synthetic record owned by the second test workspace. The same request with the record owner's test account confirms the expected access path.
Remediation
Check workspace membership on the server before returning the record. Apply the check to every record access path. Add a cross-workspace regression test.
Retest criteria
Reject the cross-workspace request. Confirm that the record owner still has access. Record the tested version and the result for each path in the agreed retest scope.
Built around your next decision
Move forward with
the risks in view.
Bring the product, the deadline and the question you need answered. We help turn them into a focused security review.
Web applications
Sign-in, roles, account recovery and the paths that handle sensitive data.
Protect the journeys your customers rely on.APIs
Authorization, tenant boundaries and what each caller can read or change.
Trace access from the request to the record.AI apps
Prompt injection, tool permissions and data access across agent workflows.
Define what the model and its tools must not do.Your engagement, step by step
From the first question
to a verified fix.
Agree on the scope, price and schedule before work starts. Keep a clear record through testing, remediation and the agreed retest.
- 01
Agree on scope
Define targets, test accounts, exclusions, timing and a contact for issues. Record written authorization before testing.
- 02
Test and document
Test the agreed paths. Record evidence, impact and limitations so your team can understand each finding.
- 03
Remediate and retest
Use the report to plan fixes. Agree on the retest scope and timing, then check the fixes against the original findings.
Method and boundaries
Evidence you can
act on.
Follow each finding from the affected behavior to the recommended fix. The report states what was tested, what remains open and where further work is needed.
OWASP Web Security Testing Guide- Before testing
- Agree on targets, environments, permitted methods, test data, exclusions and stop conditions. Confirm who can authorize the work.
- In the report
- Explain the affected behavior, evidence, impact and remediation. State untested areas and limits. Separate confirmed findings from open questions.
- After fixes
- Retest the agreed findings. Record whether each fix resolves the issue and which questions remain.
- Outside the scope
- No unsolicited scans. No testing of third-party systems without their authorization. No certification or claim that a system is breach-proof.
Before you start
A few clear answers.
Can you test a production application?
The environment is a scoping decision, not an assumption. Discuss production constraints, test data, impact limits and stop conditions before any authorization.
Do I need to send credentials now?
No. Start with a public URL and a short description, if you can share them. Do not email passwords, API keys, tokens or customer data. Any required access is arranged after scope is agreed.
How are price and timing decided?
They depend on the systems, access and testing scope. Request a review to discuss the work. An inquiry does not book an engagement or create a charge.
Your next review starts here
Know what needs fixing.
Give your team a way forward.
Tell us what you are shipping and when. We will help define the review.