Skip to main content
Solana Beta

Return to Answer

deleted 4 characters in body
Source Link
terorie
terorie
  • 463
  • 3
  • 11

This is indeed a tricky problem. Because browser frontends are inherently untrusted from the perspective of the server-side, there is no bulletproof way to verify whether a request is really coming from a specific frontend. As soon as your RPC URL has been shared, it is technically possible to spoof requests.

To limit other website frontends (dApps) from making requests to your websiteRPC you can check the Origin header server-side. Individual users and mobile clients can still trivially spoof this header. More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Since you cannot restrict the inflow of requests, you can at least limit the kinds of requests that your server responds to (using a reverse proxy such as NGINX). For example, you could block all RPC methods that your website doesn't need and check for specific arguments (e.g. program ID). This can make your RPC useless for unrelated use-cases and thus less attractive for abuse.

All of the above are just workarounds though. Ideologically, imho it is the user's responsibility of getting their own RPC access, instead of just relying on whatever a dApp serves them (verify > trust, and so on).

This is indeed a tricky problem. Because browser frontends are inherently untrusted from the perspective of the server-side, there is no bulletproof way to verify whether a request is really coming from a specific frontend. As soon as your RPC URL has been shared, it is technically possible to spoof requests.

To limit other website frontends (dApps) from making requests to your website you can check the Origin header server-side. Individual users and mobile clients can still trivially spoof this header. More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Since you cannot restrict the inflow of requests, you can at least limit the kinds of requests that your server responds to (using a reverse proxy such as NGINX). For example, you could block all RPC methods that your website doesn't need and check for specific arguments (e.g. program ID). This can make your RPC useless for unrelated use-cases and thus less attractive for abuse.

All of the above are just workarounds though. Ideologically, imho it is the user's responsibility of getting their own RPC access, instead of just relying on whatever a dApp serves them (verify > trust, and so on).

This is indeed a tricky problem. Because browser frontends are inherently untrusted from the perspective of the server-side, there is no bulletproof way to verify whether a request is really coming from a specific frontend. As soon as your RPC URL has been shared, it is technically possible to spoof requests.

To limit other website frontends (dApps) from making requests to your RPC you can check the Origin header server-side. Individual users and mobile clients can still trivially spoof this header. More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Since you cannot restrict the inflow of requests, you can at least limit the kinds of requests that your server responds to (using a reverse proxy such as NGINX). For example, you could block all RPC methods that your website doesn't need and check for specific arguments (e.g. program ID). This can make your RPC useless for unrelated use-cases and thus less attractive for abuse.

All of the above are just workarounds though. Ideologically, imho it is the user's responsibility of getting their own RPC access, instead of just relying on whatever a dApp serves them (verify > trust, and so on).

Source Link
terorie
terorie
  • 463
  • 3
  • 11

This is indeed a tricky problem. Because browser frontends are inherently untrusted from the perspective of the server-side, there is no bulletproof way to verify whether a request is really coming from a specific frontend. As soon as your RPC URL has been shared, it is technically possible to spoof requests.

To limit other website frontends (dApps) from making requests to your website you can check the Origin header server-side. Individual users and mobile clients can still trivially spoof this header. More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Since you cannot restrict the inflow of requests, you can at least limit the kinds of requests that your server responds to (using a reverse proxy such as NGINX). For example, you could block all RPC methods that your website doesn't need and check for specific arguments (e.g. program ID). This can make your RPC useless for unrelated use-cases and thus less attractive for abuse.

All of the above are just workarounds though. Ideologically, imho it is the user's responsibility of getting their own RPC access, instead of just relying on whatever a dApp serves them (verify > trust, and so on).