Start with the scope and the real boundaries

For a financial platform, I would start by defining what a meaningful security outcome looks like: a person can access only the records they should, sensitive actions preserve the intended controls, and the resulting evidence is useful to the people responsible for the system. That gives the review a purpose before choosing a technique.

Bitso’s public brief names specific web and mobile targets; it does not authorize every related property. Some sandbox-named hosts are explicitly excluded. I would turn the current target table into a small scope register and check it again before each new line of inquiry. A familiar brand, a shared login screen or an apparently related service would not extend that boundary.

  1. Record the permitted product or application, the relevant rule, the planned observation and the person responsible for deciding whether to proceed.
  2. Keep prohibited paths—social engineering, disruptive traffic and third-party supply-chain attacks—off the plan. Stop and clarify any uncertain boundary instead of following it automatically.
  3. Agree what would count as evidence of impact before collecting anything. An interesting response or a scanner warning alone would not settle the question.

Sources: Bitso Managed Bug Bounty Engagement — public program brief

Prepare the accounts and environment

The brief requires the researcher email domain @bugcrowdninja.com and a researcher-identification header. I would complete that setup through the documented route, confirm that the identification is applied consistently and keep the exact header format with the working instructions. Those are prerequisites to planned testing, not tasks this article claims have already happened.

I would prepare a small set of researcher-controlled accounts and synthetic records, with a clear label for their intended roles and ownership. I would also record the application version, platform and relevant settings. For anything involving financial state, the available testing arrangement and acceptable transaction boundaries would need to be understood before attempting a state-changing step.

  1. Confirm the required account setup and traffic identification against the current brief; treat an unresolved registration or approval step as a checkpoint.
  2. Define which controlled account owns each test record and what every other controlled account should be allowed to see or change.
  3. Keep credentials and personal information out of the evidence packet. Record environment details that another authorized reviewer would actually need to reproduce the observation.

Sources: Bitso Managed Bug Bounty Engagement — public program brief

Choose the questions worth investigating

Bitso highlights access control, authentication and financial logic among its priorities. I would translate those themes into a short set of questions about intended behavior, rather than assume a particular weakness exists. Which ownership decision protects a record? What changes after an account or session transition? Which financial operation must remain correct if processing is interrupted?

The order would depend on the evidence available and the effort needed to answer each question safely. I would favor a narrow hypothesis with a clear expected result over a large collection of loosely related observations. For newly disclosed vulnerabilities, I would also check the program’s 14-day waiting policy. Implementation details that are not public would stay as questions for the engineering owners, not descriptions of how Bitso’s systems supposedly work.

  1. Write each hypothesis as an expected rule, a controlled observation and a stop condition. Keep the expected result separate from the observed result.
  2. Prioritize questions with a plausible effect on a protected operation or record; do not assign severity from the name of a bug class alone.
  3. Use an uncertainty list to distinguish missing context from a demonstrated control failure. Revisit that list as the evidence becomes clearer.

Sources: OWASP Web Security Testing Guide

How I would structure the review

For an authorization review, I would describe a small permission matrix: controlled identities on one axis, controlled resources and intended actions on the other. The point would be to establish whether the same ownership rule holds where it matters, including the server-side decision. A disabled interface control would not, by itself, explain what the underlying authorization layer enforces.

For financial logic, I would first write the invariant in ordinary language: an operation should have the intended effect once, an invalid transition should not change protected state, and an interruption should leave a state the owner can explain and reconcile. These are proposed review questions, not claims that Bitso violates them. Any concurrency-related validation would require an explicitly acceptable method and a tightly controlled environment; I would not generate uncontrolled parallel traffic.

  1. Move one question at a time from expectation to observation, using only the accounts, records and methods permitted for that review.
  2. Compare behavior across relevant interfaces only when each interface is in scope; do not infer that one result proves another application has the same implementation.
  3. Stop when the next step would expose another person’s information, exceed the agreed traffic boundary or create an uncontrolled financial effect.

Sources: OWASP Web Security Testing Guide

Build evidence someone else can reproduce

I would build the evidence packet as the review progresses. It would describe the prerequisite state, the controlled actors and objects, the expected behavior, the smallest relevant observation and the resulting effect. The goal would be for an authorized reviewer to understand the claim without reconstructing an entire browsing session or relying on the author’s interpretation of a screenshot.

Evidence should also explain its limits. If a behavior appears only in one application version, that distinction belongs in the report. If a response suggests an issue but the protected operation has not been shown to change, I would say so. I would preserve enough context to support reproduction while redacting secrets and avoiding unnecessary collection of personal or financial information.

  1. Keep timestamped, redacted observations with the relevant environment and application version; preserve the original sensitive material only where an authorized review actually requires it.
  2. Separate what was observed, the inferred explanation and the questions still unanswered. A plausible root cause remains a hypothesis until the owner can verify it.
  3. Describe business impact through the affected permission or invariant, including preconditions and coverage limits, rather than inflate it into a claim about every customer.

Sources: OWASP Web Security Testing Guide

Turn an observation into a practical fix

If evidence established an authorization failure, my proposed fix would begin with the decision that should protect the operation. A possible implementation would bind the resource lookup and permission check to the authenticated actor and relevant ownership context, using a consistent enforcement point. The correct design would depend on the actual architecture; I would not prescribe a middleware change without understanding where the operation is authorized.

If the evidence instead established a financial-state problem, I would work from the violated invariant. Depending on the implementation, useful options could include an atomic state transition, an idempotency mechanism, a uniqueness constraint or a reconciliation check. These are alternative engineering tools, not a universal patch recipe. I would ask which layer owns the guarantee, what happens on failure and how an operator would recognize an incomplete or conflicting result.

  1. Connect each proposed change to a specific observed failure and name the assumption it relies on; avoid a broad refactor presented as a necessary security fix.
  2. Plan a limited rollout with an accountable owner, signals that show the intended behavior and a rollback approach appropriate to the change.
  3. For stateful changes, explain how existing records and in-flight operations would be handled. Rolling back code alone may not restore a previously changed business state.

Sources: OWASP Web Security Testing Guide

Verify the fix and check for regressions

I would consider verification a separate piece of work from implementing the change. The original controlled case should demonstrate the corrected behavior, but a useful regression check should also preserve the legitimate path. A fix that simply prevents every account from completing an operation might remove the symptom while introducing a different production problem.

The implementation owner’s own test environment would be the place for repeatable engineering regression tests. I would want positive and negative permission cases, relevant account-state transitions and the failure conditions that matter to the proposed fix. That does not imply permission to run an automated suite against a live engagement. Any live follow-up would still depend on the current program rules and the agreed review boundary.

  1. Recheck the smallest original case and a legitimate comparison case, recording the expected and observed outcomes for both.
  2. Where a fix protects a state transition, verify duplicate, interrupted and rejected operations in the owner-controlled environment, including the expected recovery behavior.
  3. Review operational signals and coverage gaps after rollout. Passing one regression case would not prove that every related path is secure.

Sources: OWASP Web Security Testing Guide

Keep the handoff clear and useful

The final handoff would tie together the boundary, the observation, the impact, the proposed explanation and the verification plan. Bitso treats a shared underlying issue across bitso.com, nvio.mx and nvio.ar as one finding. I would therefore explain any supported cross-domain reach in a single coherent account, while avoiding an assumption that similar-looking behavior necessarily has the same root cause.

I would close with the decisions still needed: who owns the change, which assumptions require confirmation, what can be checked before release and what should be watched afterward. Findings and supporting material would follow the program’s reporting and disclosure process. That leaves a practical record of the next change, its owner, the evidence behind it and the check that will show whether it worked.

  1. Provide one concise reproduction narrative with clear prerequisites, the minimal evidence, the demonstrated scope and the limits of the claim.
  2. Keep remediation options distinct from agreed implementation decisions, with a named verification owner and explicit remaining questions.
  3. Preserve an understandable decision trail so that another authorized person can continue the work without repeating the same uncertainty or overextending the original evidence.

Sources: OWASP Web Security Testing Guide

Sources & further reading

This post sets out a planned research approach using public program information. Actual findings follow the program’s reporting and disclosure process. Scope should be rechecked before testing.