Problem z ukierunkowanymi i dobrze przeprowadzonymi atakami jest taki, że dość trudno je zauważyć. Dzieje się tak ze względu na dużą liczbę połączeń obsługiwanych przez bazę. Według analityków firmy Forester, typowa baza może przyjmować do 20 tys. połączeń na sekundę. Bez dodatkowych mechanizmów ochronnych trudno dostrzec, co dokładnie się dzieje. Tym bardziej, jeżeli atakujący zdecyduje się na krótki, kilkusekundowy atak.

Zagrożeniem technicznym, który sieje największe spustoszenia w bazach, jest SQL Incjection. Mówi się także, że atak tego typu wypiera mający do niedawna palmę pierwszeństwa Cross Site Scripting i - mimo ogólnej powszechności - jest zabójczo skuteczny. Jak twierdzi Tom Cross z IBM X-Force, liczba ataków SQL Injection wzrosła z 2,5 tys. dziennie w 2007 r. do ok. 600 tys. dziennie w połowie 2009 r. Ataki SQL Injection w dużej mierze wiążą się z błędami w projektowaniu aplikacji webowych. Jeżeli atak się powiedzie, napastnik może np. pominąć konieczność zalogowania, wyciągać dane z bazy, wprowadzać w niej modyfikacje, czasami wykonywać polecenia systemowe, czy wreszcie potraktować bazę jako repozytorium dla kodu złośliwego. Przykładowy scenariusz takiego ataku pokazano w ramce 1.

Jak wspomniano, wiele zagrożeń dla bezpieczeństwa bazy wiąże się z konfiguracją kont użytkowników. Typowym problemem jest tutaj nadużywanie uprawnień. Polega ono na wykorzystywaniu przez użytkownika nadanych mu uprawnień niezgodnie z przeznaczeniem. Za przykład może posłużyć aplikacja obsługi transakcji: użytkownik, aby móc zaakceptować zlecenie, może otrzymać dostęp do danych płatnika (włącznie z numerem karty kredytowej czy danymi teleadresowymi) i potem je wykorzystać, ściągając np. listę numerów kart kredytowych z nazwiskiem i datą ważności karty. Pseudoataki tego typu są dość trudne do wykrycia bez specjalizowanych narzędzi. Użytkownik przecież niczego nie przełamuje ani nie omija.

Z powyższym łączy się także problem przyznawania nadmiernych uprawnień. Często użytkownicy mogą więcej, niż rzeczywiście potrzebują do wykonywania swoich zadań. Jeżeli mamy do czynienia ze zdeterminowanym sprawcą, który ma konto ze standardowymi uprawnieniami, to może on próbować zwiększyć swoje uprawnienia. Cel ten najczęściej jest osiągany przez przeprowadzenie ataków przepełnienia bufora wymierzonych przeciwko słabym punktom systemu. Wystarczy prześledzić bazy podatności, aby stwierdzić, że baza może być podatna na ten atak w wielu miejscach, np. błąd w usługach serwera bazodanowego czy błąd w stored procedures. Jak donosi Secunia, w 2009 r. zarówno dla baz Oracle, jak i Microsoftu czy MySQL, PostreSQL - zanotowano przynajmniej kilka podatności umożliwiających skuteczne zaatakowanie bazy.

Celem ataków mogą padać także protokoły sieciowe. Większość oprogramowania bazodanowego komunikuje się wykorzystując protokoły, które nie doczekały się publicznie dostępnej dokumentacji. Możliwe jest więc znalezienie w nich długo niezauważonej luki. Dzięki temu może dojść do obchodzenia mechanizmów uwierzytelniania czy przekazywania nieautoryzowanych zapytań, np. INSERT.

Innym problemem jest słabość mechanizmów audytu. Z reguły monitoruje się tylko to, co związane jest z niepowodzeniem i trudno o takie podejście mieć pretensje. Niestety, w rezultacie bardziej inteligentne ataki mogą pozostać niezauważone.