Hacker News Reader

Comment by hombre_fatal | Hacker News Reader

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?

View on HN

> Tripping up hare-brained security scanning tools sounds like a perk tbh.

Heh, not a bad criticism. Though TBH, I think all DAST tools are hare-brained. They get sold as automated penetration tests, but they really can't figure out SPAs at all, since they often only look at the immediate response to an HTTP request, when often, you'd need to see exactly what the JS code does with the response and how it gets rendered in the page. Maybe a PUT/POST request to upload data returns a blank 200 OK, but only a follow-up GET request will actually show the result.

They end up with more false negatives than false positives. At best, they'll catch the low-hanging fruits involving missing headers that often lead to Beg Bounties like Clickjacking or missing HSTS.

The only reason DAST still exists is because compliance frameworks still list it as a checkbox. Otherwise, I think they're pretty useless.

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?

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

Well client side routing is fundamentally broken unless you do serve a 200 and the index

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.

Indeed, for a cost-effective approach with a static host, why not generate placeholder HTML files for all valid routes at compile time? Alternatively, using Astro or a similar tool would be a wise choice :)

This isn’t really feasible, think about how dynamic routes can be? Can you generate a route for every ID of a thing?

I have actually seen this approach for SSG. You define a function to get all IDs, then the framework renders all of the pages using those.

Well you could plausibly do this with nano-web, simply disable SPA_MODE and generate your routes in this manner.

Reply on news.ycombinator.com