https://programming.dev/comment/24515044
Same problem is present here. Uses JWT’s for auth.
Edit:
Using jwt’s for auth isn’t bad, it’s good and quite common The problem is when they are used in place of actual bearer/cookie/session auth methods. As I understand it at least, a jwt token with a lifespan greater than 5 minutes is a red flag.
This is a browser extension that shows you the non fandom instances of wiki’s, if they exist. Or, it can also use breezewiki as a privacy preserving frontend to fandom pages.
The indie wiki’s aren’t usually federated, though.
Calling an enterprise-grade platform
Except you use JWT’s for auth, which is idiotic and a security nightmare. No enterprise that cares about security would ever accept this.
More info: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452
There are other problems, some of which I can see… and some of which I can’t. The problem is that I am not a comprehensive expert, I can only spot a few things here and there. Even if I was an expert, why would I audit your software for free lmao? Pay me for that shit.
What I do know, is that vibecoded apps are bad at security. Many, many vibecoded apps have been hit by horrific security bugs like remote code execution, xss, or authentication bypasses. That shit is simply unacceptable and should be extremely rare in modern apps. The fact that I’m not skilled enough to find them reliably makes me even more cautious and concerned around apps like yours.
It’s not just about the app architecture, but also about you. When a known community figure creates an app, I have confidence that they will have a good security posture and architecture. With vibecoding… not so much.
If you have an actual architectural critique
Nice bait, but the problem is this: Just because you get people to audit “critique” your software, doesn’t fix the root cause of those problems — you. Just because you manage to re-vibecode the app to not use JWT’s or to fix any other number of issues someone would point out, doesn’t actually mean more issues exist that that person missed. Like if someone specialized in python, then they might miss database issues, and so on. The second problem is that inevitably, you will expand this software, adding more features… and vulnerabilities. That is to say, even if you manage to fix the architecture and security now, you have not demonstrated the requisite skill needed in order to keep it fixed.
Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.
Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container
Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:
https://pen.blahaj.zone/supakaity/weve-been-hacked
I have a comment on that post with some potential solutions, that would have cut off attack paths.
Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.
But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.