To browse the internet on sensitive websites (government websites, banks, etc...), is it as safe to use a modern web browser as a programming language? Specifically, python + requests + beautifulSoup for example?
closed as unclear what you're asking by Arminius, ThoriumBR, forest, Steffen Ullrich, multithr3at3d Jun 16 '18 at 3:09
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Modern browsers are massively complicated pieces of software: they can run at least one complicated interpreted language, handle a bunch of different types of media files, and connect to a wide range of services, which can use a whole range of different methods to transfer data in both clear text and encrypted forms. That tends to mean there are a lot of things that could go wrong resulting in data being exposed to an attacker.
However, they are also subject to a lot of scrutiny when it comes to the security aspects. They implement careful memory management for sensitive pages, isolate tab contents from other tabs, have vigorously tested encryption libraries, and in many cases get constantly fuzzed looking for flaws in processing routines. Chrome has (At time of writing) about 1500 CVE issues, but, and this is quite important, the majority of these are fixed quickly.
On the other hand, a script which loads a specific site and performs one specific actions is relatively simple, even if it uses pre-built libraries to do heavy lifting such as performing SSL connections. That makes it less likely to contain issues caused by unexpected interactions between components, but it is used by fewer people, so any issues less likely to be discovered. It probably doesn't make any attempt to ensure that passwords and other sensitive information isn't written to disk inadvertently, and may even contain hard coded credentials, which could be exposed if the system it is running on is compromised. It relies on the developer to keep encryption libraries up to date, and to handle any changes to the responses from sites which are required (e.g. if the site uses an API with an Authorization header added by JS, the script will either need to run the JS, or perform equivalent steps and add the header when required).
The script is also unlikely to handle things like HSTS headers or give alerts when certificates don't match expectations, meaning that if it is used on an insecure network, an attacker may be able to intercept the traffic generated.
The threat models for each are different: the script is likely to be vastly less secure if an attacker is able to compromise the system where the script is running, while an attacker who can place malicious code in an advert shown on a sensitive page is likely to be more successful against users of full browsers - a script is probably going to ignore the advertising code, or not be vulnerable to the methods used to try escape the browser sandbox.
Personally, I'd stick with the browser though - the developers are thinking of problems I've not even considered, and implementing fixes for them without me needing to lift a finger, and as long as I keep my browser up to date, these improvements just turn up like magic.