The simple answer is nobody can prove that an algorithm won't break in a given period of time. The achievable goal is increase the probability that no effective attack will be developed without warning. There are a couple of characteristics which increase the probability that a particular cipher will remain secure and if degraded will do so 'gracefully'.
1. Time. Time is the major test of an algorithm's strength. The fact that researchers all around the world have had a decade to break SHA-2 and so far failed is a good sign. It doesn't mean that SHA-2 won't be broken tomorrow but the risk of that is lower today than when the algorithm was new and untested. For that reason I have more confidence of the security of SHA-2 relative to SHA-3. Sometimes older is better.
2. Widespread usage. Time gives experts the opportunity to attack an algorithm but it doesn't mean much if nobody has broken xyz algorithm for a decade if nobody has tried to break xyz algorithm for a decade. A break on a major algorithm (SHA-2, AES, ECC) is a big deal and will attract more attention that some algorithm your brother cooked up so this a reason to not roll your own.
3. Bit strength. 128 bit security (2^128 operations) is for all practical purposes beyond brute force both today and for a long time in the future. So why are there algorithms with higher bit strength if 128 bit is 'unbreakable'? It is an insurance policy. Many attacks reduce the complexity of an attack. So instead of 2^128 operations to find a collision it might 'only' take 2^90 or 2^84. Those are larger numbers but it is feasible given enough time, money, and improved efficiency (Moore's law). On the other hand a break which reduces the complexity for a collision from 2^256 operations to even 2^160 is not usable. One should migrate away from the algorithm because there would be an increased risk that more sophisticated attacks would reduce that further but it would not present an 0-day risk.
4. An open transparent cryptographic algorithm/system It should go without saying that you shouldn't be trusting your secrets to closed source systems which can't be independently verified but this happens more often than you might imagine. Whole drive hard drive encryption for example is notorious for being a 'magical black box'. Optimally you should be able to independently verify how the hash or cipher text is being produced. Cryptographic algorithms are deterministic. So if a device or software claims to be using AES-256 then given the same inputs (cleartext, key, IV) it should produce the same output as another AES-256 implementation.
5. Nothing up my sleeves. Most cryptographic systems require some form of constants. It is always a risk that the constants chosen were chosen because they reduce the effectiveness of the system in a way known to the author but not others. 'Random' constants are a red flag because random values are unprovable. If an algorithm uses e971c59327cabde08439c813b70dae1a as a constant and the author says don't work it was generated on a CSPRNG you should be alarmed. How can you verify that e971c59327cabde08439c813b70dae1a was the result of a random roll and not deliberately chosen because it weakens the algorithm. Nothing up my sleeve numbers are usually used as a way to introduce pseudorandom constants. For example using the first 32 bits of the fractional part of the square root of the first n prime numbers. There is a low risk that such numbers could be chosen and also satisfy the conditions that would weaken the algorithm.
Provably secure hashing algorithms
There are 'provably secure' hashing algorithms. Most hashing algorithms use rounds of mix, rotate, and reduce functions. The 'problem' is there is no way to prove that there is no faster way to find a collision than a brute force search for example. Provably secure hashing algorithms are based on mathematical proofs of known hard problems (like integer factorization). The 'provable' comes from the fact that it can be shown in a mathematical proof that a collision (or some other attack) will require a given number of operations in worst case scenario as long as no faster solution for the underlying mathematical problem is known. If that assumption turns out to be false so does the stated security but it does provide a stronger theoretical foundation as many of these mathematical problems are well understood.
The problem with provably secure hashing algorithms is they generally tend to take longer and require more resources for a given level of security when compared to traditional hashing algorithms. SWIFFT is an example of a provably secure hashing algorithm. It is not suitable for all circumstances so this isn't an endorsement of that algorithm for any particular usage.