5 ms·

> SPA_MODE when set to 1 404 request will return /public/index.html as a 200. oof, as someone who frequently has to run DAST tools, returning a 200 for somethi

> SPA_MODE when set to 1 404 request will return /public/index.html as a 200. oof, as someone who frequently has to run DAST tools, returning a 200 for something that should be a 404 is the bane of my existence. The tool will try to request sensitive files by trying something as simple as fetching hxxps://example.com/../../../etc/passwd. If you return a "200 OK", it will flag as a security issue, even if the resulting data isn't a passwd file. I don't think you can convince me that returning a 200 OK and some default content for a URL that doesn't exist is ever the correct thing to do. If you want to use 301 or 302 to redirect them to the front page, that's probably fine, but the most correct thing to do is 404.

__jonas 3y ago
But if it's an SPA, how else would you handle this case? How is the webserver supposed to know in advance which URLs the SPA is able to handle?
- phanimahesh 3y ago
  Handle a prefix maybe?
- ch_sm 3y ago
  I typically keep all my SPA routes/route names in a single JSON, and then reference those from the App, instead of repeating the routes everywhere. I can then pass those to the server to let it know what the SPA can handle.
  - antihero 3y ago
    This is an opinionated approach that is out of scope really I think. Though if it works for you, awesome!
    - shkkmo 3y ago
      I'm not sure what is 'opinionated' about this approach. It seems like a pretty standard and reasonable way of correctly serving an SPA in a way that doesn't violate web standards.
      - __jonas 3y ago
        So this would mean you would have to dynamically generate your webservers configuration at the build time of your SPA? And then how are you handling routes with params inside? In your SPA they would probably be configured like /user/:id/post/:post Now you would have to translate that to something the webserver config understands, probably wildcard / glob pattern / regex stuff and splice that into the web server config? I mean it's possible, sure, but that's a lot of overhead and room for error just to deploy a simple SPA, it definitely is an opinionated approach.
        withinboredom 3y ago
        I don’t know. Computers are pretty damn good at transforming text. It sounds pretty simple really, it’s probably less than a week to build something rock solid.
    - boredtofears 3y ago
      I'd say not handling 404's correctly and simply returning a 200 OK is pretty opinionated, too.
  - rizky05 3y ago
    [dead]
- Sohcahtoa82 3y ago
  I'm confused here. What defines the "webserver" versus the "the SPA"? The way I've implemented SPAs is to run nginx. All my JS and CSS is in /static/ and served up by nginx. "/" returns an index.html. "/api/*" gets forwarded to a back end of some sort, usually Python's Bottle because it's lightweight and simple to use. If the route doesn't exist, Bottle returns a 404. If I have an endpoint that includes an ID of some sort in the URL, like /api/getobject/12345, but you request an object that doesn't exist, then I still return a 404. How are you implementing SPAs in a way that you can't return a 404?
  - __jonas 3y ago
    > How are you implementing SPAs in a way that you can't return a 404? Not specifically me, but a lot of SPAs have their own routing. So you would go to https://my-spa.com/user/39820002/post/39811155 When you hit that route, the webserver returns /index.html with the JS bundle, the JS runs and matches the user ID and post ID from the URL and then maybe makes some API requests to fetch content of whatever, I mean the SPA doesn't have to be backed by an API anyways, could be purely static but still use a router. In the React world, react-router is (was) pretty popular: https://github.com/remix-run/react-router https://github.com/remix-run/react-router That's a library that works exactly that way, relying on every route being passed to the JS bundle for handling, so the webserver needs to be configured to never return 404 and just return the index.html for every route, here is an example of what this looks like from the docs of Caddy, another popular webserver with a pretty easy to understand config format: https://caddyserver.com/docs/caddyfile/patterns#single-page-apps-spas https://caddyserver.com/docs/caddyfile/patterns#single-page-... It's a "Single Page App", you may have many pages being rendered by this app, but it's a single html page that is responsible for doing this. Now – SPAs are not as popular as they used to be, and there is an argument to be made that they aren't the best solution in most cases with what's available now, regardless of that they do exist and this appears to be a web server specifically for them so having the option handle SPA routing as it's commonly done, does make sense. And I think for stuff like internal management apps, admin panels etc. SPAs with their own routing are still a decent solution.
    - fragmede 3y ago
hombre_fatal 3y ago
Tripping up hare-brained security scanning tools sounds like a perk tbh. > I don't think you can convince me that [...] is ever the correct thing to do It's just a matter of trade-offs. Serving the app.js on a 404 can cause things like browser/caching issues that are confusing for the user, and 404 isn't necessarily correct since the app is both servable and recoverable from that url. And I'm not sure 302-redirecting is any less meaningless than serving 200 on a not-found. The user doesn't need the redirect since the app is already capable of handling the not-found page in a user-friendly way. So does it somehow improve things for programmatic analysis of the app to make all 40X errors redirect to the homepage, and is that very compelling?
- eddd-ddde 3y ago
  If I make a typo and get a 200 for some url that doesn't actually exist, my browser will now happily suggest that url when I'm typing something in the future. Is there a benefit for doing so?
  - shawabawa3 3y ago
    It's not a benefit but a side effect of client side routing If your main routing logic is in your JS app your server can't know if a route exists or not unless you duplicate routing code across front end and backend
  - antihero 3y ago
    Well client side routing is fundamentally broken unless you do serve a 200 and the index
    - shkkmo 3y ago
      You only have to serve a 200 and the index for valid routes to have frontend routing working. The complaint is serving a 200 for invalid routes, which breaks all kinds of things and violates web standards.
      - 3y ago
antihero 3y ago
But how could this possibly be correct if the route is correct within the context of the client side code which uses history API to route, which the server knows nothing about? Else you’re going back to the days of hash routes which nobody likes.

__jonas 3y ago

But if it's an SPA, how else would you handle this case? How is the webserver supposed to know in advance which URLs the SPA is able to handle?

phanimahesh 3y ago
Handle a prefix maybe?
ch_sm 3y ago
I typically keep all my SPA routes/route names in a single JSON, and then reference those from the App, instead of repeating the routes everywhere. I can then pass those to the server to let it know what the SPA can handle.
- antihero 3y ago
  This is an opinionated approach that is out of scope really I think. Though if it works for you, awesome!
  - shkkmo 3y ago
    I'm not sure what is 'opinionated' about this approach. It seems like a pretty standard and reasonable way of correctly serving an SPA in a way that doesn't violate web standards.
    - __jonas 3y ago
      So this would mean you would have to dynamically generate your webservers configuration at the build time of your SPA? And then how are you handling routes with params inside? In your SPA they would probably be configured like /user/:id/post/:post Now you would have to translate that to something the webserver config understands, probably wildcard / glob pattern / regex stuff and splice that into the web server config? I mean it's possible, sure, but that's a lot of overhead and room for error just to deploy a simple SPA, it definitely is an opinionated approach.
      - withinboredom 3y ago
        I don’t know. Computers are pretty damn good at transforming text. It sounds pretty simple really, it’s probably less than a week to build something rock solid.
  - boredtofears 3y ago
    I'd say not handling 404's correctly and simply returning a 200 OK is pretty opinionated, too.
- rizky05 3y ago
  [dead]
Sohcahtoa82 3y ago
I'm confused here. What defines the "webserver" versus the "the SPA"? The way I've implemented SPAs is to run nginx. All my JS and CSS is in /static/ and served up by nginx. "/" returns an index.html. "/api/*" gets forwarded to a back end of some sort, usually Python's Bottle because it's lightweight and simple to use. If the route doesn't exist, Bottle returns a 404. If I have an endpoint that includes an ID of some sort in the URL, like /api/getobject/12345, but you request an object that doesn't exist, then I still return a 404. How are you implementing SPAs in a way that you can't return a 404?
- __jonas 3y ago
  > How are you implementing SPAs in a way that you can't return a 404? Not specifically me, but a lot of SPAs have their own routing. So you would go to https://my-spa.com/user/39820002/post/39811155 When you hit that route, the webserver returns /index.html with the JS bundle, the JS runs and matches the user ID and post ID from the URL and then maybe makes some API requests to fetch content of whatever, I mean the SPA doesn't have to be backed by an API anyways, could be purely static but still use a router. In the React world, react-router is (was) pretty popular: https://github.com/remix-run/react-router https://github.com/remix-run/react-router That's a library that works exactly that way, relying on every route being passed to the JS bundle for handling, so the webserver needs to be configured to never return 404 and just return the index.html for every route, here is an example of what this looks like from the docs of Caddy, another popular webserver with a pretty easy to understand config format: https://caddyserver.com/docs/caddyfile/patterns#single-page-apps-spas https://caddyserver.com/docs/caddyfile/patterns#single-page-... It's a "Single Page App", you may have many pages being rendered by this app, but it's a single html page that is responsible for doing this. Now – SPAs are not as popular as they used to be, and there is an argument to be made that they aren't the best solution in most cases with what's available now, regardless of that they do exist and this appears to be a web server specifically for them so having the option handle SPA routing as it's commonly done, does make sense. And I think for stuff like internal management apps, admin panels etc. SPAs with their own routing are still a decent solution.
  - fragmede 3y ago

hombre_fatal 3y ago

Tripping up hare-brained security scanning tools sounds like a perk tbh. > I don't think you can convince me that [...] is ever the correct thing to do It's just a matter of trade-offs. Serving the app.js on a 404 can cause things like browser/caching issues that are confusing for the user, and 404 isn't necessarily correct since the app is both servable and recoverable from that url. And I'm not sure 302-redirecting is any less meaningless than serving 200 on a not-found. The user doesn't need the redirect since the app is already capable of handling the not-found page in a user-friendly way. So does it somehow improve things for programmatic analysis of the app to make all 40X errors redirect to the homepage, and is that very compelling?

eddd-ddde 3y ago
If I make a typo and get a 200 for some url that doesn't actually exist, my browser will now happily suggest that url when I'm typing something in the future. Is there a benefit for doing so?
- shawabawa3 3y ago
  It's not a benefit but a side effect of client side routing If your main routing logic is in your JS app your server can't know if a route exists or not unless you duplicate routing code across front end and backend
- antihero 3y ago
  Well client side routing is fundamentally broken unless you do serve a 200 and the index
  - shkkmo 3y ago
    You only have to serve a 200 and the index for valid routes to have frontend routing working. The complaint is serving a 200 for invalid routes, which breaks all kinds of things and violates web standards.
    - 3y ago

antihero 3y ago

But how could this possibly be correct if the route is correct within the context of the client side code which uses history API to route, which the server knows nothing about? Else you’re going back to the days of hash routes which nobody likes.