fix: reject malformed unsigned requests instead of crashing before signature check

[sahiljagtap08]

Summary

Fixes #1447

Public endpoints get hit by scanners and bots that send any JSON shape. Bolt builds the request context (team id, user id, and so on) when the BoltRequest is created, which is before the RequestVerification middleware runs. A body with the wrong value types, a JSON array, or broken JSON raised TypeError, AttributeError, or JSONDecodeError. The result was a 500 for a request that should have been a 401.

This follows the non-breaking approach suggested in the issue thread: make the context extraction robust instead of moving it behind the middleware.

Changes:

• Every extract_* helper in slack_bolt/request/internals.py checks the value type before using it (authorizations, enterprise, team, user, channel, event).
• parse_body treats non-object JSON (array, string, number, null) and invalid JSON as an empty body, so the request still reaches the signature check and is rejected there.
• build_context and build_async_context guard the shape of response_urls.
• Comments explain why each guard exists.

Testing

• New unit tests in tests/slack_bolt/request/test_internals.py cover the malformed shapes for every extractor, build_context, and parse_body.
• New end-to-end tests in tests/scenario_tests/test_app.py and tests/scenario_tests_async/test_app.py send unsigned malformed bodies to App and AsyncApp and assert a 401 (previously an exception).
• Ran ./scripts/format.sh, ./scripts/lint.sh, ./scripts/run_mypy.sh, and the full test suite. All existing tests pass.

Category

• slack_bolt.App and/or its core components
• slack_bolt.async_app.AsyncApp and/or its core components
• Adapters in slack_bolt.adapter
• Others

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've run ./scripts/install_all_and_run_tests.sh after making the changes.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @sahiljagtap08 to sign the Salesforce Inc. Contributor License Agreement.

[srtaalej]

thank you for opening this PR @sahiljagtap08 💟 looking pretty good! i'll give it a more thorough review once the CLA is signed and CI passes 😸

[sahiljagtap08]

recheck

[sahiljagtap08]

@srtaalej thanks for taking a look! The CLA is signed now and the check is passing. Let me know if you'd like any changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.59%. Comparing base (a9dee3b) to head (afd575d).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1586      +/-   ##
==========================================
+ Coverage   91.54%   91.59%   +0.04%     
==========================================
  Files         228      228              
  Lines        7285     7303      +18     
==========================================
+ Hits         6669     6689      +20     
+ Misses        616      614       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[srtaalej]

thanks @sahiljagtap08 for putting this together, and signing the CLA 🙏 we tested it locally, and it does what it says: malformed unsigned bodies that return a 500 on main now get a 401.

after talking it over as a team, though, we've decided to take a different approach, so we're going to close this PR.
the underlying problem is that Bolt parses the body and builds the context in BoltRequest.__init__, before RequestVerification runs. so untrusted input gets processed before we know the request came from Slack.

we'd rather fix the order of operations so unsigned payloads are never parsed. that means moving body parsing and context building into a middleware that runs after RequestVerification
🫰

[sahiljagtap08]

Thanks for testing it and for the explanation @srtaalej. Moving the parsing behind RequestVerification makes sense. Happy to help with that change if useful.