feat(api): allow configurable CORS policy

[walldiss]

Implementation ideas

We need to allow users to configure CORS policy. It should accomodate both secure and easy to configure way to set up CORS for different usecases.

• if skip-auth is enabled CORS should allow any origin
• default CORS setting should be strict mode(no cors headers)
• have a config field to add more to Access-Control-Allow-Origin manually

[TheRealSibasishBehera]

Hi

I’m new to the project and would love to work on this issue. Before I start, could you clarify some details not covered in the description or the approach in the previous PR?

1. Access-Control-Allow-Methods – Which HTTP methods should we expose by default?
   Is "GET, POST, OPTIONS" sufficient, or would you like a broader/narrower list?

2. Access-Control-Allow-Headers– similar question: what default header list (e.g., "Content-Type, Authorization") do you expect, and should we allow users to extend or override it via the same config file/CLI flag?

3. Do we permit the wildcard ("*"), for either methods or headers, or should that be restricted to origins only?

Once I confirm these, I can put together a PR. If it sounds good, could you please assign the issue to me?

Thanks!

[walldiss]

Hi @TheRealSibasishBehera – thanks for jumping in!

---

Clarifications

• Origins

  • Default = strict (no CORS headers) unless the user enables cors-enabled or runs the server with --skip-auth.
  • When --skip-auth is on, we allow Access-Control-Allow-Origin: * because the instance is already insecure by design.
  • If cors-enabled is set, users supply an explicit cors-allowed-origins / allowed_origins list.

• Methods

  • Default (secure mode): GET, POST, OPTIONS.
  • Insecure (--skip-auth) mode: Access-Control-Allow-Methods: * (all methods).
  • Users can still extend the default list in secure mode via --cors-allowed-methods or the config file.

• Headers

  • Default (secure mode): Content-Type, Authorization.
  • Insecure (--skip-auth) mode: Access-Control-Allow-Headers: * (all headers).
  • Same extend/override mechanism (cors-allowed-headers) applies in secure mode.

• Wildcards

  • Wildcard (*) is permitted for origins, methods, and headers, but only when --skip-auth is active.
  • In secure mode we restrict wildcards to prevent accidental over-exposure.

---

Settings related to enabled CORS can be a new CORSConfig struct and added to to RPC config in nodebuilder.
If this matches your understanding, please go ahead and open a PR and I’ll review. I’ve assigned the issue to you. Let me know if any clarification needed. Thanks again!