There is little doubt that with a language that has no pointers (or strongly discourages pointers) and has run-time checks on array and buffer access will have far fewer problems with buffer overruns and similar issues than with a language that allows free and rampant access.
But let me give you a few specific points here, to avoid help avoid going round in circles:
- There is /nothing/ in C that stops you checking your arrays and buffers. People who are experienced in reliable and secure programming write their C code carefully in order to avoid any risk of overflows.
- With C, there is a lot more specified at compile-time than with dynamic languages. So if you have written your C code well, and use appropriate static error checkers (there are many such tools for C and C++), a great many potential bugs are caught at compile time. With dynamic languages, bugs often do not appear until your code is running - and if you don't have good tests covering all code paths, you will not see the bugs until after the system is in use.
- High-level languages make it much easier to avoid memory leaks and issues due to unclear resource ownership. But they don't avoid such problems entirely, and they use far more resources in order to achieve this automation.
- High-level languages make it much easier and safer to work with strings. C is crap at strings.
- With C, when you get buffer overflows and similar problems, the result is usually a hard crash. With dynamic languages, the result is usually a run-time error. People often write error-handling code for the errors they expect, but fail to do so for errors they don't expect. So a run-time error or exception when you try to go out of bounds in your dynamic language will lead to improperly handled errors - you'll get weird error messages, program halts, silent incorrect operation, etc. It is unlikely that you will get the same kind of read or write of random memory that you can get with C, but injection attacks (popular with SQL) can be easier to exploit, and unexpected errors can easily lead to skipping security checks and other protection.
- Regardless of the language, you have to /think/ securely if you want to keep your system secure and reliable. You have to check /every/ assumption about the incoming data, and sanitise everything. No programming language does that for you - you always have to think about it. But /frameworks/ and libraries can help, and make sure that the data delivered to your code is safe. Choosing a good framework is far more important than choosing the programming language.
- Regardless of the language, you need to test /everything/. And you need a development process in place to ensure everything is tested, that code is reviewed, that test procedures are reviewed, etc. - all by different people.
As you can see, there are pros and cons to high and low level languages. You can write secure and insecure code in either. I don't know of any statistics showing some languages to be "safe" and others "unsafe", taking into account the amount of times the code is run, the number of attempted attacks, the level of expertise of the people writing the code, and the amount of time and effort spent writing and testing the code.