The reason we don't like to give opinions is because "is this secure?" and "should this be fixed?" vary wildly from circumstance to circumstance and some security steps are not worthwhile for every company. My stereotypical example is that an anonymous site to vote for favorite cat pictures does not need anywhere near as much security as the web portal for launching nuclear missiles. Your security needs probably fall somewhere in the middle.
Putting it in context
Neither can be answered without understanding the actual risk. Effectively what your team has developed is a permanent session identifier. Gitlab, for instance, did something similar, and were aware of it and left it unaddressed for quite some time before fixing it. The reason why it may not be a high priority is because a permanent session identifier is not a vulnerability on its own. Every system has session identifiers, or API keys, or something else that the client uses so that the server will remember who it is and let it back in. To some extent, this is just more of the same. If an attacker were to get a hold of a standard session identifier (perhaps by stealing cookies in an XSS attack) then the exact same things that you are concerned about would result: the attacker would have full access to the account and would be able to do anything that doesn't require password confirmation.
Additional risks
However there are three differences between your permanent access code and a typical session identifier:
- Your access code is permanent.
- Your access code is widely shared.
- Your access codes are included in the url itself
These can be dangerous in some circumstances. The permanency is an issue. A normal access code can at least be invalidated automatically or on log out, giving an attacker who gains it a limited window to act in. An attacker who steals a permanent access code gains access to the account permanently. That is a bit of a problem.
The fact that the access code is commonly shared also increases the risk. Normally access credentials don't leave cookies. Emailing them around makes it easier for them to leak accidentally: sent to the wrong address, sent via an email provider that doesn't use encryption, etc...
Finally, allowing the access code to come up in the URL gives it more avenues to be stolen, since url data may be cached in intermediate servers or stored to logs, depending on https usage. If you are using https then this may be less of a concern (since the exact URL is also encrypted while the request transits across the internet).
Weighing your options
Ultimately your team needs to understand the actual risks, and if you consider this dangerous you won't have any success changing people's minds otherwise. Saying "Guys this is dangerous and we need to change it!" will likely get shrugs. Explaining why this is dangerous and how it may be taken advantage of by attackers may be much more convincing. Certainly, your team should treat it for what it is (i.e. full account access) and protect it accordingly. Also, you need to make sure it is long enough that it can't be brute-forced.
Even still, in some cases a system like this may make perfect sense. As an example this is no different than Google Drive's "Share URL" scheme which generates a URL that you can share with anyone, and therefore grant them full access to a document. Perhaps your team (and your customers) find the convenience of a simple URL to log themselves in to be worth the potential security concerns. Then again, if this is an e-commerce store and someone can break in and order things for themselves, or if you are storing anything privacy focused, or any number of other scenarios, the potential risk of an attacker using this to get into someones account may not be worth the convenience. Ultimately that's a decision for your team and your customers to make (keep in mind that your customers may make their opinion known by leaving if this results in a wildly publicized data breach).
